We’ve worked on dozens of accessibility projects over the years, and have helped nonprofits, associations, businesses, and regulated industries navigate the tricky waters of accessibility compliance.
We are excited to launch our five-part series on Product Leader’s Guide To Accessibility & AODA with Simone Abel - Director of Digital Strategy at Enginess. Over the next couple of weeks, we will post several articles sharing the best practices and key recommendations around implementing accessibility and AODA with your project.
BLOG SERIES
A Product Leader’s Guide To Accessibility & AODA
Part 1: Understanding accessibility compliance
Part 2: Project delivery
Part 3: Managing costs
Part 4: Ongoing maintenance
Part 5: Common risks and pitfalls
Can't wait to see more tips? Download the complete guide today.
How to Avoid Common AODA Risks and Pitfalls
We do a lot of accessibility projects. And over the years, we’ve seen plenty go smoothly. But we’ve also seen everything that can go wrong. So in this final blog post, we put together a list of the most common risks, pitfalls, and project roadblocks we’ve seen derail website compliance — and how to avoid them.
Most CMS software today can and should support accessible front-end design and code patterns. A less frequently encountered but showstopper cause for accessibility projects going off the rails is when a CMS isn’t compatible and has to be completely ripped out and replaced, or it’s core re-developed / upgraded.
A CMS migration - or core tune-up - is an entirely new project on top of the accessibility and compliance one you may have scoped. If your CMS is not going to support accessible patterns, you’ll have to address this first and foremost.
The question then become 'what do we do'? The best solution that we’ve seen is to simply separate the projects into their components — the accessibility and compliance project, and the CMS upgrade or migration. This is yet another great example of why it’s so important to involve accessibility early in the SDLC as well. It’s entirely possible for a CMS to work perfectly for the rest of the organization while being fundamentally broken for accessibility specialists.
By splitting the projects — and even shelving the accessibility project until the CMS is dealt with, makes it far easier for product owners.
In this final chapter we explore the following risks and pitfalls and show you to avoid them, which include:
- Alienating your existing users
- Legal ramifications of making a mistake / inaction
- Failing to design a common design language
- Failing to account for the total cost of ownership of one- off costs
- Trying to force every change into a single project
Download the complete guide today: A Product Leader’s Guide To Accessibility and AODA.
