Why accessibility in software matters
When you think about your typical workday, how much time do you spend working on a computer? 50% of the time? 80%? 90%? How hard would it be for you to perform your job if you did not have access to a computer? Technology has become ubiquitous, both in our personal and professional lives. So much so that the United Nations published the following in their Convention on the Rights of Persons with Disabilities:
Article 9 – Accessibility
To enable persons with disabilities to live independently and participate fully in all aspects of life, States … shall … ensure to persons with disabilities access, on an equal basis with others [...] to information and communications, including information and communications technologies and systems ...
To put this in some context, in 2011 the World Health Organization (WHO) published the World Report on Disability and estimated that about 15% of the global population suffers from some form of disability.
In this day and age, if you are excluded from using technology, you are at a serious disadvantage. Software vendors should strive to be as inclusive as possible, making sure everyone has the same access to the services and tools we provide.
The journey of accessibility at Sonar
Humble beginnings
In 2018, Laura Wacrenier, the company’s sole UX Designer at the time, noticed that some users were complaining about our products on Twitter and in our Community forums. The reason for their complaints: the lack of accessibility of SonarQube. She triggered conversations with these users to better understand the situation and even had a chance to speak via video conference with some users that suffer from blindness, asking them to show her how they used our software. Soon, Laura started raising awareness among her colleagues that we should be more inclusive when building our products. This was the initial spark that got Sonar to think about accessibility. Later the same year, in December, I joined the company as a web developer. Accessibility was a topic that was dear to me as well, and I was happy to find like-minded people in my new team. We quickly started thinking about new ways to try and improve the situation.
In 2019, Laura and I organized an internal company event for the Global Accessibility Awareness Day to raise awareness at the company level about accessibility; it was a great success. Over the following 2 years, teams tried to tackle it with the "clean as you code" approach, taking accessibility into consideration when building new features. However, all this was on a best-effort basis. As many folks can probably relate, making accessible UIs is not easy. It requires specific skills and expertise. And if it's not a top priority, it can be difficult to find the time to do it right.
Taking accessibility to the next level
Fortunately, in 2021, Sonar announced internally that it was becoming a priority: we would work to become WCAG 2.1 AA compliant for all our products. This gave teams the freedom to dedicate time to making our products more accessible.
Baby Steps
True to our company’s Baby Step approach, the SonarQube Team decided to set a limited target: let’s focus first:
- On the Community Edition (our most popular edition)
- On users that are developers (which make up the vast majority of our user base)
- And on the “project space” (i.e., non-admin, project-related pages)
This reduced scope had 2 benefits:
- Its impact would be very high, covering the vast majority of our users
- It was large enough to be ambitious but small enough to be achievable within a reasonable time frame
The audit showed us that, considering the complexity of the SonarQube UI, we had done surprisingly well so far. True, we had a lot of issues, but none were considered “blockers”, i.e., even if using the application was hard for some users, nothing inherently prevented them from using it. But more importantly, the audit was incredibly useful: not only did we now have a better view of what we needed to work on, the audit greatly helped us get a better understanding of why some things weren’t accessible, and how we could fix them.
We decided to split this new backlog of accessibility issues into multiple sprints: we would then dedicate 1 or 2 sprints each release cycle (approximately 2 months) to work on them. This would allow us to make good progress and keep a high level of energy and motivation, while still being able to work on the SonarQube feature roadmap.
Where we stand today
SonarQube 9.6 is the first release to benefit from dedicated accessibility improvements, and we’re proud to have tackled more than a third of all the issues uncovered in the audit. We’ve already started working on further improvements for 9.7, and are confident we will have treated all issues found by the audit by the time we release 9.8. This means that the next SonarQube LTS will be the most accessible version of SonarQube we ever released.
Don’t get us wrong: it won’t be perfect and we won’t be WCAG 2.1 AA compliant yet. This is only the beginning.
The future of accessibility at Sonar
Our current objective is to have follow-up audits, each one focusing on a fixed scope. We will spend several cycles fixing all the issues uncovered by the audit, before moving on to the next scope. And so on and so forth, until we will have covered SonarQube as a whole. This way, little by little, cycle by cycle, we will continuously improve, until we reach our target of being as close to WCAG 2.1 AA compliance as possible. There will likely be areas where it will be impossible to be fully WCAG 2.1 AA compliant (e.g., the Activity graphs, by their dynamic nature, are very hard to make fully accessible). Once we have reached our target, we are considering having annual accessibility audits, to ensure we don’t regress and continue to meet high accessibility standards.