For many years, I’ve seen repeated – and have myself repeated – the idea that an accessible website is not more expensive. That idea comes with a notable caveat. That caveat, to sum it up, is that it is not more accessible to build an accessible website from scratch than it is to build an inaccessible site from scratch.

Building from scratch. When was the last time you built a website from scratch? What does it mean, in 2022, to build a website from scratch? Is it realistic, for the average business owner, to even consider this option?

Obviously, building from scratch comes in different flavors. If you bake a cake from scratch, you are not expected to mill the flour yourself, milk your own cows, or raise your own chickens. There are always components you’re receiving from third party sources.

As a result, the accessibility of your site is conditional on the quality of components you’re using in your project.

So component choice is an enormous factor in the accessibility of the end product.

What does this mean for development costs?

The path where the cost of an accessible site matches the alternative is when everything is custom. That also depends on a development team with an early and active engagement with accessibility. That’s not a realistic scenario for most sites, so I’ll ignore that scenario.

If we look at the basic process of building a new WordPress site, it’s likely to follow a common pattern. You select a theme, a collection of plugins, and apply design and layout. The theme could range from a complex site builder to a simple starting point like Underscores. Plugins will depend on feature requirements, but may include e-commerce, calendaring, forms, or advanced search tools.

If you’re aiming for an accessible site, every decision comes with a delicious side of assessment. Every development project needs to match a feature set to the site’s goals. After that, you also need to assess the accessibility of the product you’re using.

Choosing Components

With 15 years of experience building accessible sites on WordPress, I have a body of knowledge that helps me make many of those decisions more quickly. However, every time I need functionality I haven’t used before, I know that I will invest a considerable time identifying a viable candidate.

I look at three major areas in assessing plugins: their default output, the fundamental accessibility of their settings, and their usage of filters and actions. If a plugin offers an “accessibility mode”, I’ll look at it, but I’ll give preference to plugins that are accessible by default.

And – so we’re totally clear – a viable candidate is a plug-in that I feel I can make accessible; not necessarily one that *is* accessible. A plug-in that I can filter, theme, or – at minimum – has usable classes and IDs I can target via scripting will be viable, even if it isn’t perfect.

As a developer focused on accessibility, I almost never use a plug-in out of the box. There is always customization. Some plug-ins are more easily customized than others, and I favor those, even if they have lower accessibility by default.

Every project requires custom code. The primary reason I started writing WordPress plugins was because I had features I needed to provide, and I couldn’t find an accessible option. Building a fully custom plugin is not my first choice, however.

Is an accessible site more expensive?

Yes, it is. There are added costs in assessment, testing, development, and in content creation. With a high-quality team that has the necessary expertise, this will be a marginal additional cost. But as site development tilts further towards enabling self-creation of professional websites, the availability of expertise goes down, and with it, the accessibility of the outcomes.

Quality comes at a price.

But expressing this as “accessibility is expensive” is also not entirely accurate. Accessibility is not expensive; inaccessibility is cheap.