Accessibility's costs are lower than you think

In my previous post, I argued that the accessibility discussion often glosses over costs (in terms of planning, implementation, and testing), and that a more successful case for accessibility would acknowledge those costs. After hearing other perspectives via comments on the post, digging further into WCAG guidelines, and participating in internal discussions/workshops, I want to amend part of that argument.

I still think the better case for accessibility is one that talks about costs, because cost is a key part of most businesses' decision-making.

But the best case for accessibility would lead with this revelation: Actually, for many websites — and certainly for many agency projects — the costs are trivial to implement and test common, high-impact accessibility items.

And if that's the case, we don't need to reframe accessibility at all. I mean, we can — but kind of who cares? If more businesses and people knew they could do the right thing and make accessible sites with little additional cost, I think most would do the right thing.

That means the key is not only to encourage more people in our industry to be well-educated about accessibility. It's to understand that an important part of that education is non-judgmentally addressing concerns — including concerns about costs — and ignorance.

And speaking of ignorance: Just because I'm an accessibility newb doesn't mean Viget is an accessibility newb. We've incorporated accessibility into many of our projects, and Jeremy, Jason, and Megan are leading internal efforts to standardize accessibility training and implementation. Viget is investing in those efforts — and in efforts like my posts — so we can do the right thing as much as possible.

Revisiting Accessibility's Costs

In my last post, I said businesses can't meaningfully contemplate accessibility without knowing the costs. I asked a hypothetical question: What if accessibility raises the cost of an average web project by 5%, or 20%, or 50%?

Based on everything I've learned since, that hypothetical is unrealistic.

To get a clearer sense of the costs, I broke down WCAG Level A and AA items based on implementation cost: zero, trivial, and non-trivial (one spreadsheet tab for each group). I'm defining "zero cost" as "requires no additional implementation effort"; "trivial cost" as "requires additional implementation costs that are low enough in the aggregate to be wrapped into overall costs"; and "non-trivial cost" as "requires enough additional implementation cost to potentially warrant specific discussion." (The spreadsheet is a collaboration with Viget colleagues, but I'd love feedback. Also, I've made up my own categories that I think are easier for newbs to digest than WCAG's principles and guidelines.)

By looking at accessibility items this way, some revelatory insights emerge:

• Most of the highest-impact accessibility items — as gleaned from e.g. the BBC's accessibility standards and John F Croston III's practical accessibility presentation — are in the zero-cost and trivial-cost buckets.
• Much of the "work" involved is simply to think about the accessibility item and/or to follow coding standards.
  • For example, for the item "Text should have certain contrast ratios," changing hex colors in a stylesheet costs effectively nothing. The work is in simply thinking upfront about which color values will have the right contrast ratios.
  • Likewise, it takes only UX thought to make sure navigation structure is consistent across the site. (As accessibility advocates point out, much acessibility work is just good coding and usability practices that we should be following anyway, and that many of us already do.)
  • Once you understand how to add skip links, the implementation effort is trivial.
• For the agency context, many of the non-trivial-cost items are uncommon or wouldn't be the agency's responsibility. For example:
  • Most sites don't use CAPTCHA or have time-based interactions.
  • The content producer or client would typically be responsible for video/audio transcripts, captions, and audio descriptions.

Based on that breakdown, I'd guess that for the average project, the aggregate cost to implement and test free and non-trivial accessibility items is in the range of a couple person-days to a person-week. For the highest-impact items alone, probably less.

Your mileage — and budgets and cost structure — may vary, of course, but for Viget that kind of cost is not worrisome. (And the cost of training and education for all this shouldn't be more worrisome than for learning any other new design/development skill.)  

Cost Questions

The biggest cost questions I have are around making JavaScript-heavy sites accessible. The WCAG guidelines don't specifically address how to make JavaScript features accessible via the keyboard or screen readers; the closest item is 2.1.1: "All page functionality is available using the keyboard, unless the functionality cannot be accomplished in any known way using a keyboard (e.g., free hand drawing)."

There's a newer set of coding conventions called WAI-ARIA that "helps with dynamic content and advanced user interface controls developed with Ajax, HTML, JavaScript, and related technologies." But it's unclear to me how far ARIA can go in terms of making Ajax and JS features accessible (and how costly that is), especially for sites whose experience is fundamentally dependent on JavaScript.

I gather this is new territory, and we'll write more about it as we learn. That also bleeds into the progressive enhancement discussion, which is a topic for a different post!