This blog post is part of a series of posts discussing the Business Case for Accessibility. In order to get a full view of the Business Case for Accessibility, I encourage you to read all posts in this series, links to which can be found at the bottom of this post.
A number of WCAG Success Criterion are cited as being beneficial to reduced design, development, production, and maintenance cost. The arguments made suggest that using more “standards-based” production techniques, i.e. CSS layout instead of tables, avoiding deprecated markup, etc., will both increase accessibility and reduce costs relating to design, development, production, and maintenance.
- Does it increase income? No. This argument is about saving money.
- Does save money?Possibly. This argument assumes people are still using things like tables for layout, which I still see here and there, but these days most developers are using more standards-based production techniques because doing so has additional benefits like making JavaScript frameworks work better.
- Does it mitigate risk? Yes. It would mitigate risk to profitability during a redesign and to project timelines.
- How strong is the evidence? Moderate. The benefit of this seems readily apparent, but I’ve not seen anything beyond anecdotal evidence.
In terms of new development, I don’t see any difference in terms of development time for something inaccessible vs. something accessible (provided the developer understands accessibility). I generally consider the level of effort to be identical for new development. Additionally, although it could be argued that some reduced maintenance time could be realized, the business always has option to not fix issues that are not related to display and operability, leaving other issues alone.
The cost savings for standards-based production would be realized more during a site redesign where the current site’s content is being retained. In a worst-case scenario (which I have seen), a site laid out in tables and riddled with deprecated markup can cause considerable headaches and cost the organization a lot of time and money to prepare the content for the new design. And this all assumes that there isn’t any re-architecture of the site’s content or application workflows.
There are a number of things which weaken this argument:
- Very rarely are companies engaging in completely new development work. Most development work is maintenance and feature requests. Even new features are often built using an existing codebase or hampered by enterprise-level constraints such as content management systems
- This argument works best when you’re redesigning interfaces but keeping content and features. By using standards-based production, it is easier to port over the content to the new interface. There are no cost savings from a redesign if you’re dumping the whole thing in the trash and starting over.
- This argument is based on time saved. As time is money, saved time == saved money, which makes sense. The ultimate way to save money, then, is to spend no time. In other words, as I’ve said before, leaving the issues alone altogether will save a lot of money.
All-in-all, I’m skeptical that this is an effective business case argument for one thing. This argument depends on a very big assumption that repairs/ modification of code is inevitable and that the changes that occur would be made easier/ better through the preexistence of accessible, standards-based production techniques. I’m further skeptical that this is an effective business case for accessibility. In the URL I cited earlier, only 6 (of 61, total) WCAG Success Criterion are mapped to this argument, 2 of which are Level AAA.