This post is a follow-up to my prior article titled “Understanding the cost of not being accessible”. If you haven’t read that one, then this one will make a lot less sense, so please check that one out first.
At the conclusion of the previous post, it is logical to determine that we’ve now come full circle on the idea that the best way to avoid spending money on accessibility is to avoid accessibility problems in the first place. This is true but, as before, that’s only an ideal-state situation where you have perfect processes, people, and tooling, and are working on a brand new product. In reality, nobody has when they first start their accessibility program or when their program is still immature.
As a reminder, Levels 2, 3, and 4 of the DAMM (Digital Accessibility Maturity Model) are “Repeatable”, “Defined”, and “Managed”, respectively. In my opinion, the primary dependency for moving beyond Level 1 is training. After all, ignorance is the root cause of why companies don’t have better accessibility and, as a result, training is really the first thing that needs to be handled. Everyone within the company should be given training on accessibility, regardless of role, beginning with basic disability awareness and etiquette. Further training should be relevant to each employee’s role and their potential work’s impact on/ interactions with persons with disabilities.
The next dependency for increased maturity would be to establish the metrics by which your success will be measured. This, in my opinion, is a core aspect of all upper levels of the DAMM. After all, your processes cannot be Repeatable, Defined, or Managed unless you’re tracking the work being performed on accessibility. How and where you track your metrics often depends on what systems you have in place and what data you have available.
Unless you have an accessibility-specific platform with which to track your metrics, it is often best to use whatever systems you have in place. This removes friction among your staff and is simply easier to implement and maintain. The example above, for instance, is from a Jira instance set up to include accessibility-related data in issue reports. This allows for the use of JQL to prioritize fixing accessibility bugs. In this specific case, the Jira instance was set up to track the following Information for each issue logged:
- Content Type
- Platform(s)
- Population(s)
- Severity
- WCAG Success Criteria
Altogether, those data points will give you the ability to do risk assessment, prioritize remediation, and determine specific skills gaps among your development staff.
In terms of the subject of this post, measuring long-term ROI, you’ll need to start tracking the time it takes to fix the issues. Many issue tracking systems, such as Jira, have this capability as well:
At Tenon, we utilized a cool plugin from Harvest that provided an ability to “punch in” and “punch out” when working on an issue. Though this might seem like an unnecessary expense for companies that aren’t billing customers for their time, it did allow for extremely granular tracking of the time spent on an issue because, in practice, we found Jira’s time tracking to be the kind of thing where time was entered after the work was done and was often a guess. In any case, the point is that you can’t set goals or measure progress against those goals if you don’t have the data. At minimum, you should be tracking how much time is spent fixing a bug and which bugs relate to accessibility.
Time is money
For accessibility ROI, your goal is to minimize the cost of disruption by minimizing the accessibility defects in your websites or software and the only way you’re going to know if you’re successful or not is by gathering the data as discussed in the section above. From there, tracking your ROI is very straightforward: As new work is created and as that work is tested, the expectation is that the issues created will be reduced as the organization matures its accessibility program. Your ROI is then the number of bugs that your products do not have.
More on that in an upcoming installment.