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.

If you are interested in learning about the next generation in Web Accessibility Testing, give Tenon.io a try.
If you or your organization need help with accessibility consulting, strategy, or accessible web development, email me directly at karl@karlgroves.com or call me at +1 443-875-7343. Download Resume [MS Word]

6 Comments

  • jimtobias
    Posted November 30, 2011 at 10:48 am   Permalink

    A couple of points:

    1. I don’t see how this article can make a good list of all the things that cost real money, and then settle for saying “accessibility costs nothing”. All those dollars are real, and have to come from somewhere. And even an opportunity cost is a real cost.

    2. The article’s model seems to be that an organization decides to adopt accessibility, and has some startup costs, but these go away once accessibility is fully integrated. I think there are always going to be maintenance costs. We’ve all seen enterprises go up and down in their commitment to accessibility, and the damage from re-orgs, strategic realignments, and staff churn is matched by the chaos of evolving technologies and accessibility tools.

    I hope we can continue this dialogue and refine it, if only because the Access Board has to do a Regulatory Assessment on the 255/508 Refresh, and that includes cost estimates. (And while we’re at it, wouldn’t it also be nice to estimate the benefits?)

    • karlgroves
      Posted November 30, 2011 at 11:27 am   Permalink

      Great comments, Jim. As I said in the article, every minute of time costs money. Given that, I suppose the most true answer to the question is: “Multiply the time you spend on accessibility by the fully loaded cost per person who does the work”. That seems to be the approach everyone wants to take toward this topic. My argument is that instead of tracking accessibility as this distinct & separate cost, we should be thinking of accessibility as part of how we do our job.

      Going back to my form labeling example in the article, there are two ways to look at it:
      1) To say modifying our textarea method so that it creates an accessible form label is an accessibility costs or,
      2) To say the modification is part of what it takes to do a good job – therefore the cost involved in the remediation is a cost of doing good work

      I don’t want to deny that doing things accessibly will add effort (and therefore money) because that’s just not true. I would like to also argue that the important part is that creating accessible ICT is no more costly once it is “how things get done” than it would be to create something that is not accessible.

      • JR
        Posted December 1, 2011 at 9:34 am   Permalink

        Back in my lead developer days, I remember people grumbling about having to consider security when developing applications. Complaints like “It’s too expensive” and “It’ll slow us down too much and make us miss our deadline” were expressed over and over again. Incorporating security into the development lifecycle did cost a great deal of money at first – updating/adding training, changing processes, modifying/adding frameworks, etc. all require extra money and resources. However, once security was fully incorporated and resources were put in places to assist projects, cost and time to market dropped significantly. Now no one thinks twice about security. It’s just part of “how things get done”.

        The same is true for accessibility. As with any new requirement, the cost will be high at first, but will no longer be an issue once it’s adopted as part of the development lifecycle.

  • Posted November 30, 2011 at 3:53 pm   Permalink

    Couldn’t have said it better.
    To be fair, though, there are indeed additional costs, as soon as you use multimedia, related to providing transcripts, captions, audiodescriptions, and possibly sign language versions (supposing you are in for the whole shebang). We could argue this is good practice anyway, and a good idea business-wise (captioned videos sell more, by a larger percentage than exepected, given the known deaf and hard-of-hearing population). Still, these are actions you wouldn’t take if not for accessibility first.
    Apart from that, this is yet another post I’ll read and re-read, again and again!

  • hassellinclusion
    Posted December 30, 2011 at 4:37 pm   Permalink

    Karl,

    Another great article. Thanks for writing it. I’m going to be referencing it around my Accessibility Myths 2011 blog, which has the whole ‘accessibility is cheap… no, it’s expensive…’ as its myth 4.

    A lot here chimes in with my thinking – the best way of helping disabled people get a more usable web is for us to help organisations to embed accessibility into their ‘business as usual’ way of working. This is exactly what the accessibility process Standard BS8878 that I’m in charge of helps organisations to do. It’s worth checking out if you haven’t already.

    The only thing I think could be much clearer in your article is the roles of people working on a website creation project.

    You talk a lot about accessibility requirements, and about using agile approaches to delivering them. I totally agree with what you say. But you confine your thinking to the people on the team creating a site who do the coding, when many of your points are equally as valid for the content creators, designers, project managers, and product managers who are also likely to be part of the team, and who also need to have accessibility embedded into their thinking for the project to deliver well (see my BS8878 slides on slideshare for how each team member’s role impacts on accessibility).

    It’s because your insights are so good that I’d want you to go farther than you do, and mention the non-technical people on the team, especially as many websites these days are created solely by non-technical people (see the second of my myths).

    A few other points…

    Re: accessibility requirements
    I love your pragmatic approach to avoid doing taking on too much from the start. I’d suggest prioritisation of accessibility requirements is based on an understanding of the purpose of the ICT product and its audiences (as advocated by BS8878’s first two steps).

    Re: integration of accessibility throughout an organization
    BS8878 is a great implementation framework for doing this, especially through its idea of an Organisational Web Accessibility Policy. I’d be interested in getting any feedback from you or your readers on the Standard. One thing I think you have to contribute to Standards like BS8878 is your pragmatic, agile approach. Whereas BS8878 gives the full roadmap to embedding, your agile approach suggests taking on what’s most useful from it and adding more as you go. That’s a good idea.

    Re: training
    I totally agree, but would expand your points to cover all the other team members who are creating the ICT product. In my experience developers are much more likely to have been trained (or trained themselves) in accessibility than the project managers and product managers who direct their work. That creates tensions where the developers want to spend their time creating things the right, accessible way, but their wishes get overridden by project managers who don’t care about that element of QA and just want something right now. Training the managers in my view is even more important than training the people who do the actual coding.

    Re: Modifying existing codebases
    Love your ‘prioritize your remediation efforts’ strategic view – this is exactly what’s needed, and is a good rationale to use for all accessibility decisions made during a project.

    Re: how expensive isaccessibility
    As Olivier says in his response, there are additional costs. I think the important thing here is to look at how costs scale. Many accessibility requirements of code can be made to scale well by embedding accessibility solutions in reusable classes and modules, as you suggest. But unfortunately many accessibility requirements of content don’t scale so well. So, it’s not the cost of creating captions which makes things expensive. It’s the fact that the costs don’t scale well – doing captions for a thousand videos takes you a thousand times the time needed to subtitle one video as you can’t reuse anything. And, unlike deciding to code accessibility rather than inaccessibly, it is very easy to track the costs of creating captions. That’s why very few organisations do it – as they baulk at paying the costs needed. As I say in my blog myth on cost, some things are cheap, and others are expensive – and website creators (and their finance teams) need to know which are which, and what the benefits arising from each are.

    Great article. Looking forward to what you write next.

    Jonathan

    • karlgroves
      Posted January 1, 2012 at 8:34 am   Permalink

      Jonathan,

      Great response, thanks for sharing. One point of clarification, if I may. You say:

      “You talk a lot about accessibility requirements, and about using agile approaches to delivering them. I totally agree with what you say. But you confine your thinking to the people on the team creating a site who do the coding, when many of your points are equally as valid for the content creators, designers, project managers, and product managers who are also likely to be part of the team”

      In an Agile environment all of these parties would be involved, so I’m not advocating an Agile approach just for developers. To be completely honest, this post (and a lot of my posts) is a soft-sell for Agile, which I view as part of a two-pronged approach to getting increased accessibility (the other being training). In an Agile environment (particularly Scrum), a team-based approach is used. In many instances there are front-end developers, back-end developers, and designers working as a cohesive team. Each team will likely have its own Scrummaster who might also be a developer or might be a dedicated PM. In some cases the PM and Product Owner/ Manager might be the same person. In any case, all of the parties you name have a role to play in Agile and all should understand accessibility and be involved in ensuring successful integration of accessibility in their process.

4 Trackbacks

Post a Comment