Contact
So you know what accessibility is. And you might know it takes a lot of work to fix an inaccessible product (so start on time!). When building a new product, making it accessible from the start does not require major additional investments. Either way, there’s a few steps you could take.
You probably want to know where you stand if you already have a product. The easiest place to start is by doing a quick scan of a product. The Web Accessibility Initiative (WAI) from the World Wide Web Consortium (W3C) has created a specific procedure to evaluate websites, the WCAG-EM, in addition to the WCAG itself. This is quite an extensive procedure, but they also have a simple, preliminary list of checks. A nice in-between method is what many service providers call a quick scan: taking a few pages and checking them for WCAG conformance, often taking version 2.2 level AA as the baseline.
Once you know where you stand, you can create an action plan. It’s hard to make improvements, though, if you lack the knowledge. That’s where training might come in. You probably want all roles (strategy, research, design, development, testing/QA, product owners, content, product managers, etc.) to know what accessibility means for their work. You could request or set up a general training for just one afternoon, or (let team members) follow an extensive course.
From the initial evaluation, you might have learned that there a few major problems. For example, your app might not work with a screen reader at all, or your main brand colour lacks the contrast with the default text and background colours. Making a prioritised list of issues and getting started on the main blockers (whether quick fixes or large projects) would be a good place to start and close the gap.
If you already have a design system, you could do a more in-depth analysis and fix the components in your library and the design system in general. This way, fixes quickly spread through all your products, and it’s easier for teams to create accessible products because the building blocks are already compliant.
If you don’t have a design system yet, though, this might be a good moment to set it up. By creating reusable building blocks, it becomes easier to build and maintain products. And with proper documentation, you make sure teams know how to use your components and make products accessible for your specific use cases and industry.
Under the European Accessibility Act, you’re responsible for all parts of your product, so also third-party plugins. If there are problems with them, a good option might be to ask the vendor to start working on their accessibility. However, in some cases you might need to replace the tools and switch to a different vendor.
When the glaring issues are fixed and you think you’re mostly compliant, you’re ready for the next step. In the same vein as how you would test general usability in a usability test, testing accessibility is possible with accessibility testing. The setup is also similar: with a test script, ask users of assistive technology to test your product.
This will uncover specific (implementation) issues and ensure your product is actually accessible. It’s also good practice when launching new features; of course you will take accessibility into account from the start, but it’s always good to check and make sure you don’t break the experience for a group of your users.
To take the next step, it’s good to solidify your new practices in your processes. Think of updating your Definition of Ready/Done, product documentation and purchasing conditions. Process wise, think of integrating accessibility in your onboarding or employee evaluation criteria.
Ideally, everyone knows all there is to know about accessibility of course, but that is not quite realistic. Still, each role which touches the product has their own accessibility responsibilities, and everyone should be aware of those responsibilities, and have the time and training to fulfil them. This goes for individual contributors, but also for management, to make sure that there is accountability within your company.
So, everyone should have a basic understanding of accessibility, and it should be part of their job description. But to acquire and develop more knowledge, it could be beneficial to also have more specialised experts. In a small company, one person might get this as an added responsibility. But for larger organisations, several experts could be placed in different product teams or roles. They could then connect through a guild, and share knowledge among them and to others in the company. Alternatively, these experts could be part of a centralised team, to help different product teams with their questions. Both options have their benefits and drawbacks, and different organisations might favour one over the other.
Even if you update all your processes, mistakes might slip through. That’s why it’s important to have a feedback and complaint mechanism. This allows users to notify you about problems they face. It’s good practice (and under the European Accessibility Act also a requirement) to publish an accessibility statement on your website or show it in your app. This shows that you care about accessibility, but also communicates what your progress is, any known issues, and your feedback mechanism.
Lastly, making your products accessible is a difficult endeavour, and you probably need some outside help. Of course, you need to hire people with impairments to help you figure out how to make your product accessible beyond the basics of the WCAG. Think of recruiting them for research activities, hiring them as testers, or for any other role. Additionally, there are organisations and agencies with accessibility expertise, who can help you get started and build your accessibility practices.
In short: it’s easy to get started with an evaluation, to at least know where you stand. There are lots of steps you can take afterwards, too, so contact us if you want help with evaluation, training, improving your design system, setting up a customised governance model, or doing accessibility testing.
This was the second post in our series on digital accessibility. In the next one, we dive into guidelines and legislation.
