It's been about a year since we started focusing on accessibility within the engineering team at Ophelos. Last year, I wrote a blog post called An Introduction to Accessible Design at Ophelos. Since then, we've made a lot of changes to increase web accessibility across all our products.
When we began looking at accessibility, it seemed pretty overwhelming. Even as a small startup, we had to answer questions such as: What should we fix first? What is the top priority? How much effort is required to fix these issues? How long can we reasonably dedicate towards accessibility within different areas of the system? There was so much to it, it was difficult to know where to start.
One year on, we’ve made some really great progress. I wanted to use this post to outline the key components that helped us build a clear, sustainable, and reasonable backlog of accessibility changes.
As a team, we invested in axe DevTools, allowing us to audit our site and allowing us to prioritise tasks based on the violations we had on our site (from minor to severe). From this, we created GitHub Issues to outline all the issues we had within the system. Originally, we recorded these as single issues for us to fix site-wide. For example, we had lots of images that were missing alt text, leaving screen reader users unable to understand what the image was adding to the page. Rather than creating an issue for each violation, we added a single issue to cover all of these. Within the GitHub issue, we added details of why the error is important, how to fix the error and, if the issue was specific enough, we added a list of violations to fix. The problem we had with issues outlined like this was that we couldn't easily know when an issue was "fixed" without running axe DevTools on every page.
For us engineers here at Ophelos, testing is a must. It's how we've built a system that we can rely on and trust, and it makes onboarding and bug fixing a lot easier for us. As we can't manually run all tests on every page every time we need to find out what accessibility issues we have, we introduced accessibility tests. These are written to run on a page or a subsection of a page and check that no accessibility violations are detected. To begin with, we wrote these with specific violations being skipped in these tests so we then knew where the issues were we were trying to fix. We also introduced an extension to this where we were notified when a violation was skipped but has since passed. This allowed us to be confident that we knew exactly what the accessibility issues were on a given page from our test suite.
Axe isn't perfect. Axe is a useful tool for detecting the "easy wins" when it comes to accessibility. It's great for identifying HTML structure issues, but it doesn't identify interactive issues with your page. For example, axe will tell you where a navigation bar isn't correctly labelled in the code; if it is, this allows a screen reader to skip the navigation bar (unless the user wants to navigate to it), so that the user doesn't have to listen to repeated content.
However, if your date picker cannot be navigated by keyboard, Axe will not detect this issue, leaving users who cannot use a mouse unable to change the date. Additionally, any non-static content (content that appears or disappears on the page) can potentially contain accessibility issues. Therefore, when testing, you need to make sure that you cover every case to ensure that your page is fully accessible.
As a startup, we have a lot of proposed features to expand our products. Refactoring our entire front-end to be fully accessible is a big ask amongst all the other priorities. Something that really helped with this was moving to a component-based front-end. We build in Ruby on Rails, and we use ViewComponents for this. As part of building out a large feature last year with lots of front-end work, we worked with our designers to create a full component library and spent our initial development time on the project building components. While we were building components, we made sure to include accessibility checks on every component as we built them. We could, therefore, ensure all our components were accessible regardless of the context in which we used them. This took care of the majority of the accessibility requirements before we even built the individual pages and hugely increased our speed of development on complex front-end features.
This is something we're continuing to work on across our products, and we aim to build a full component library that can be used across all of our products. Once we've completed building a full component library, we will then be refactoring the older legacy areas of our site to utilise these components too. This is ongoing work, but as engineers, we're really seeing the benefits of prioritising accessibility ahead of building new features.
Of course, we couldn't just stop all new feature development to rebuild all of our site in an accessible way, so we had to be smart about our prioritisation. First of all, we fixed any and all severe accessibility violations within our site. Luckily, these changes didn't take us long, so the next step was working out how to prioritise the less severe violations.
Instead of prioritising each violation individually, we prioritised our products according to the level of expected traffic. By this, I mean all customer-facing journeys and products were fixed first, then all client-facing products, and finally, our internal products. Our customer-facing products are always the most important. They're used by a much larger group of people, and so the importance of accessibility scales with the traffic on this journey.
We also could not spend all of our time fixing existing journeys, and we have a long backlog of upcoming features to build. So we assessed within our customer-facing product which pieces of the journey were not due to be redesigned. It's not as important to fix the old designs if we'll be replacing them within the next few months. It's more important to make new designs accessible as we build them.
The priority for the business will always be to create new features, so investing all our time and resources into accessibility wasn’t feasible. To address this, we took an incremental approach by leaving everything a little better than we found it. In doing this, we've gradually increased accessibility across our site. Everything that has been redesigned or updated is (mostly) now accessible. There are, of course, some changes that were just too big to do along the way, but with our continuous focus on accessibility, as we scale our products, these should become fewer and fewer.
Overall, our journey towards web accessibility has been a rewarding one. We've learned a lot along the way, and we're proud of the progress we've made so far. Building a roadmap, automating tests, and moving to a component-based front-end are just a few of the strategies that have helped us prioritise accessibility changes and make significant improvements to our products. While we still have work to do, we're committed to continuing our efforts to make our site as accessible as possible for all users.
