.png)
Accessible software refers to software which can be easily used by anybody, regardless of disability, device or circumstances. Every user should receive the same quality of experience in terms of ease of use, perception and understanding.
The WCAG (Web Content Accessibility Guidelines) grades accessibility from A, the lowest, to AAA, the most accessible. According to AbilityNet over 90% of websites don’t meet single-A compliance. Being inclusive is no longer just an ethical practice, but a legal one too - as of 2021, the legal minimum in the UK is AA.
There are many different audiences who interact with websites in different ways to consider when building accessible software. According to the WHO, 15% of the world’s population has some kind of disability, though accessible design is not just about considering those with disabilities or those using assistive technology; you also need to consider people who are interacting with your site on a mobile, people with slow internet connectivity or even people using older browsers.
Nowadays the majority of standard HTML elements do comply with accessibility standards, though many websites sacrifice accessibility in favour of a more complex design. At Ophelos we’re making a commitment to make our software accessible for all and keeping it that way.
Here’s a challenge for you…
Most modern computers come with an inbuilt Screen Reader. To appreciate the importance of accessible design, try turning it on, closing your eyes and trying to navigate around one of your favourite websites.
If you are using a Mac you can find it in ‘Accessibility’ in Settings. If you are on a Windows, go to Settings, Ease of Access, Narrator.
How easy is it to find what you’re looking for?
How confusing is it to try to navigate to other pages only using your keyboard?
Why accessibility matters at Ophelos
At Ophelos, making our website accessible to everyone is a top priority. Our company aims to empower customers to take control of their finances and take action to pay off their debts in a sustainable, realistic way that works with their budget.
We don’t want to create any barriers to a person’s financial freedom and so making sure that all aspects of our self-serve platform can be accessed by all of our users is essential.
We work with a lot of people in vulnerable situations at Ophelos. Being behind on payments can make a person financially vulnerable, as well as bring a great deal of stress. On top of this, StepChange estimate that 1 in 5 customers have an additional vulnerability on top of their financial hardship. We are committed to supporting these customers and need to make our software and payment options available to everyone regardless of their vulnerability.
As an engineering team we strive to build the very best software, so excluding customers is simply not an option. We really care about helping people out of debt and our board have committed to investing money into making our product accessible to all.
Realistically, it takes a lot of time and energy for companies to make their product accessible so as to help relatively small numbers of people, albeit in significant ways. Financially, it might not make sense. But we’re doing this because it is ethically the right thing to do.
Our Engineering Journey
This is the first time that I have looked in depth into accessibility as an engineer. Since I have started researching and rebuilding accessibly, it has completely changed how I think about building software.
Accessibility is not an afterthought and inaccessible code is no longer acceptable - we think of inaccessible software as a bug.
Here are some things we’ve started doing to ensure that accessibility is woven into our engineering process:
- We invested in axe DevTools which scans all the pages on our site and flags up accessibility issues.
- Taking what we learn from axe DevTools, we have created a roadmap of inaccessible issues that we need to fix. We’re in the process of making these changes now.
- We now discuss accessibility in our design meetings together with our product team.
- We discuss accessibility when planning new features and talk about the best practices as a team.
- We have created automated tests for accessibility and we make sure to cover each of them when we fix any flagged issues.
- Our acceptance criteria for code changes includes accessibility checks and validations.
As individual engineers, we are all committed to building accessible software long term. We recently created personal development plans for the year and have individually decided to pursue the Certified Professional in Accessibility Core Competencies (IPACC) certification in 2022.
As a team we have also committed to having our site externally audited for accessibility once we have completed our roadmap.
We will be creating a series on blogs on the specifics of how we are tackling accessibility issues in our site, so stay tuned for more!
