What do CTOs need to know about accessibility and technical debt?

Did you know accessibility can be helpful for keeping down 'technical debt'? Does your Chief Technical Officer (CTO) know this? 

What is technical debt?

Technical debt (also known as 'tech debt' or 'code debt') is 'the mess which slows everything down' - the coding updates and adjustments that need to be done in software development following software upgrades or changes.

Accessible code doesn’t need to be an additional burden on CTOs, with a long list of tickets in the backlog. Accessible code improves code maintainability, readability and abiding by best practice reduces the accumulation of technical debt whilst ensuring the product is future proof for new technologies that may emerge or new legislation such as the European Accessibility Act (EAA).  

Embedding accessibility into your tech debt management or refactoring is a cost-effective approach to gradually ensure your team are trained, upskilled in writing accessible code whilst being ready for the European Accessibility Act (EAA) deadline in 2025.

And, with the looming 2025 EAA deadline, companies that haven’t made any progress towards and accessible product are going to be in a hurried rush to meet legislation or face significant and costly legal risks.  

So, why not get ahead of the competition?  

Need help with navigating accessibility legislation and the European Accessibility Act, and what this means for your digital accessibility priorities?

The relationship between accessibility and technical debt 

Technical debt accumulates over-time for a variety of reasons, such as a need to prioritise rapid feature delivery over long-term code quality, which means that inconsistent coding practices can creep in.

The impact is a less maintainable and readable codebase, eventually slowing the rate of feature development.  

Digital accessibility is, in addition, often viewed as something to tackle later at the end of a project. Thus, risking an increase in overall technical debt if large changes are required to meet guidelines.

Instead of seeing accessibility as a last-minute fix, what about embedding accessibility into your refactoring process? And how can this help with managing tech debt?  

1. Standardisation and consistency:

Accessibility guidelines like WCAG (Web Content Accessibility Guidelines) emphasise consistency and the use of standardised elements. For example, using semantic HTML elements such as <button> instead of custom <div> components not only improves accessibility but also reduces the need for custom code that becomes difficult to maintain over time.

By adhering to these guidelines, your team adopts best practices, creating a more uniform, learnable and manageable codebase. Great for keeping momentum when deploying features and reducing costs when onboarding new team members. 

2. Maintainability: 

As teams refactor with accessibility in mind, they are forced to simplify code. For instance, accessibility features like keyboard navigation and screen reader support often require a cleaner Document Object Model (DOM) structure.

This streamlining reduces the complexity of the codebase, making it easier for developers to identify and fix issues, leading to fewer bugs and less time spent on maintenance. 

3. Automation and Tooling: 

There are a growing number of automation tools, such as Axe Linter or GitHub Actions, that can help identify and enforce accessibility standards. These tools reduce the manual effort involved in ensuring compliance and prevent the introduction of new technical debt by catching poor coding practices, reducing the time taken for those who review pull requests. 

Auditing Western Power Distribution's website

Using accessibility to help communicate the value of tackling technical debt to stakeholders 

For many CTOs, one of the biggest challenges is justifying to stakeholders why resources should be dedicated to tackling technical debt instead of new feature development. While the long-term benefits may seem obvious to the technical team, the business side often needs more concrete reasons.  

1. Cost-Benefit Analysis: 

This is where accessibility can really help move the conversations forward because not only will you be tackling tech debt, but there’s also the added business value of enabling more customers to use the product and reducing the risk of litigation.

The 2025 EAA will make accessibility mandatory for most digital products, and failure to comply could result in legal challenges, fines, or lost customers. Proactively addressing accessibility as part of your technical debt strategy will mitigate these risks and prevent an expensive up-front rush later to meet EAA. 

2. Future-Proofing: 

Accessibility improvements don’t just benefit a small subset of users; they make your product usable by a broader audience, therefore increasing market reach.

Additionally, accessible code is often more adaptable to future technologies, such as new assistive devices or browsers, meaning your product should require less firefighting to update and remain relevant and puts you into a better position to scale as new technologies emerge. 

3. Operational Efficiency: 

When you invest in accessibility-driven refactoring, you’re also improving the overall efficiency of your development team.

Many of the principles underlying WCAG such as using semantically correct HTML is just good code practice. And cleaner, more maintainable code means faster future development cycles, fewer bugs, and smoother onboarding for new developers, all of which translate into long-term savings. 

Provide data to your senior managers about global trends in digital accessibility: 

Actions to embed accessibility into the refactoring process 

1. Automate where possible: 

Incorporate automated testing and linting tools that enforce accessibility standards as part of your Continuous integration / Continuous Deployment pipeline with tools such as Cypress-axe. It’s another layer that will help catch accessibility issues before they enter production. 

2. Gradually upskill your team: 

Ensure that your developers are trained to incorporate accessibility best practices into their code during the refactoring process. This doesn’t mean overhauling entire team or large up-front investment.

Instead, you can focus on gradual learning by leveraging automation and tools like VSCode Axe Linter to help developers identify issues as they code. Manual testing will always be an important part of accessibility, but at least the team will slowly build knowledge and of how to find the most common and easily resolved issues problems.  

3. Audits and manual testing  

By the time you are ready, it’s worth seeking a professional to complete a manual audit to find any issues the team may not have been aware of. However, if you have already been upskilling the audit will be yet another tool for learning.

At AbilityNet, we provide details reports and recommendations for resolving issues with the opportunity to speak to a consultant. Once an audit is complete and the fixes implemented, we complete a recheck to validate they have been resolved.

Therefore, if there are gaps in knowledge or WCAG guidelines the team are having challenges with, it becomes easier to target team training to be the most effective.  

Invest in accessibility now for long-term growth

Accessibility offers a unique opportunity for CTOs, tech leads and software teams to address technical debt while simultaneously future-proofing products.

Far from being an additional burden, accessibility-driven refactoring leads to a cleaner, more scalable codebase, operational efficiency, and ensures compliance with upcoming regulations like the EAA.

By investing in accessibility now, you’re not only reducing future costs but also positioning your product for long-term growth and success.

Further Resources

• Keep up to date with accessibility issues with the AbilityNet newsletter 
• Discover more accessibility and inclusive design training for Content and Designers
• Find out about AbilityNet's free live webinars
• Unsure where to start with digital accessibility? Speak to our experts for help