Are you prepared for it to take 7 months (or more) to make your website accessible?

If you’re like me, you don’t go to the store until you’re ready to buy something. There’s a difference between window shopping and shopping, and I usually don’t go into the store and look at specific products until I’m ready to buy. When it comes to web accessibility, most customers are the same way. It is very rare for someone to start looking for a vendor to help with their site’s accessibility before they have a specific need. What that means is that the day they start looking for that help is Day 0. Your decision, at Day 0, is whether you want someone to sell you an audit or to just fix the darn thing.

Let’s take a look at the audit scenario, since that’s what gets sold most often.

Lead-to-close: Days 0 to 71(ish)

On the vendor’s side, we start counting “Time to Close” from whenever a potential customer reaches a certain stage in the deal lifecycle. A lot of companies start counting from when they become an Opportunity, but for our purposes, let’s use when the customer is a lead. That’s the earliest phase in our pipeline. We’ve had one conversation with this person, we think they probably have BANT, and we’ve added them to our pipeline management software for further discussion. Using historical data, it will take around 71 days before the deal closes.

As the table above shows it typically takes around 2 1/2 to 3 1/2 months from that first good conversation until there’s a signature on paper that describes and authorizes the work to be performed. No actual work begins before the deal is signed, of course, and yet you’ve taken at least at 71 days from the time you decided you need the help. Not that you’re to blame, of course. There’s a lot of back and forth to be done on contract approvals and things like that, but this is still the reality. The 2^nd longest time delay on getting your digital property accessible is the deal itself.

Time to deliver the audit: Days 72 to 113(ish)

Depending on the vendor company’s workload work can begin the next day. Realistically it could take anywhere from a few days to a few weeks before the actual work begins. From there, it can take around 41 days before the work is delivered.

At the end of this process, you now have an audit. The quality, clarity, and level of detail in an audit deliverable can vary quite significantly. I’ve seen everything from a spreadsheet of vaguely worded issues to extremely detailed write-ups in Word documents a few hundred pages long. If you’re going the audit route, you definitely want the greatest level of detail possible. After all, you’re probably going to pay a significant amount of money on the audit. You want it to contain enough detail that your development staff can understand not only what the problem is but why it is a problem and how to fix it.

The biggest mistake you can make as a customer purchasing an audit is not looking at sample deliverables first. You’re not paying for a list of problems. You’re paying for detailed guidance on how to make those problems go away. So before buying an accessibility audit, ask to see a sample deliverable. If they don’t have one, run away. If they do have one, read through it and ask yourself: “Can I understand exactly what work is needed to fix the issues in this audit?”. If you cannot answer in the affirmative, find another vendor.

Time to fix: Days 114 to 205+

Here’s where the real problem with accessibility audits begins to come into focus. It is now 4 months or so from the time you first searched for help on your website’s accessibility and all you have in that time is a list of problems that you need to fix.

The level of detail in the audit deliverable is critical in being able to effectively take action on the results. But there’s also a lot of other things at play when it comes time to fixing the issues in the audit.  Altogether it means that once the audit is in hand, it could take more than 90 days before the website is fixed.

Audits are a speed bump. But so are the existing developers.

At 205 days – almost 7 months – from the time you decided that you need accessibility help, you might finally have an accessible website. There are 3 reasons this stuff takes so long:

1. The procurement process sucks. Unfortunately, there’s not a lot you can do about this. The bigger your company, or the more you’re spending, the longer it is going to take. The best thing you can do is select a vendor who is responsive to your needs.
2. The audit itself is a speedbump. Audits take a long time. The all-in time can take around 6.5 business hours per tested component/ page, and you can’t start fixing things until the audit is in hand.
3. Once the audit deliverable is in hand, work begins to fix the site, often by the same people who created the accessibility problems in the first place.

I know that last point sounds harsh, but it isn’t. The overwhelming majority of accessibility issues aren’t created out of malice but by ignorance. Most web developers don’t have experience with accessibility and lack the in-depth knowledge needed to fix the issues in an audit effectively the first time. What ends up happening instead is a lot of back-and-forth with your accessibility auditor asking for additional guidance or asking for retesting.

There’s a better way, and it doesn’t take 7 months

Rewinding back to Day 0, it is important to consider what you’re after. When you, or your company, made the decision to seek out help on your website’s accessibility, did you set out to get an audit? Or did you set out to find a way to make your website accessible?

This is an important distinction. Many people look for a vendor to do an audit because that’s what they’re used to hearing about. Or, their Google search has led them to a bunch of results for websites advertising accessibility auditing. But that’s because for most accessibility consultants, all they have are hammers and accessibility audits are their nails. As a customer, what you want is a website that is accessible. So why not hire someone to make the website accessible?

Here’s what it should look like

Go back to Day 0 and add on the time for the initial time-to-close: 71 days. Now, use the same time from the audit, which is about 41 days, but apply it to fixing the site instead of auditing it.  The next 90 days? They don’t exist, because instead of auditing the site, it is getting fixed.

Having a team of accessibility experts actually fixing your site is much faster for 3 important reasons:

1. A team of experts can test while they fix.
2. A team of experts can get it fixed right the first time.
3. Experts already know (most of) what’s wrong.

The importance of expertise, in this scenario, cannot be overstated. Sufficiently experienced experts know the most common error patterns and can (should) attack those at the outset of the project. The typical audit is an exercise in cataloging repeat instances of the same types of issues that an experienced accessibility expert has already seen time and again. While there will certainly be issues that exist outside of the most common patterns, the time used to catalog the predictable issues can be spent doing remediation.

It is time for this new paradigm

Accessibility professionals need to take a much more proactive role in fixing systems. The current state of the accessibility industry is one in which “consultants” are in the business of delivering problems: Our tools simply tell the users about a pile of problems and audit reports are little more than a list of problems. The reason why overlays are so popular is because customers don’t want a list of problems, they want solutions. We need to change the paradigm to one where we’re delivering solutions. It is time that we start fixing the problems that we find.