Our final post as a part of our new series ‘A Product Leader’s Guide To Accessibility & AODA’. Here we cover the common AODA pitfalls digital teams encounter once they set about building new products.
We’ve worked on dozens of accessibility projects over the years, and have helped nonprofits, associations, businesses, and controlled 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 subsequent weeks, we’ll post several articles sharing the simplest practices and key recommendations around implementing accessibility and AODA together with your project.
How to Avoid Common AODA Risks and Pitfalls
We do tons of accessibility projects. And over the years, we’ve seen plenty go smoothly. But we’ve also seen everything which will fail. So during this final blog post, we put together an inventory of the foremost common risks, pitfalls, and project roadblocks we’ve seen derail website compliance — and the way to avoid them.
Most CMS software today can and will 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 got to be completely ripped out and replaced, or it’s core re-developed / upgraded.
A CMS migration – or core tune-up – is a completely new project on top of the accessibility and compliance one you’ll have scoped. If your CMS isn’t getting to support accessible patterns, you’ll need to address this first and foremost.
The question then becomes ‘what can we do’? The simplest solution that we’ve seen is to easily separate the projects into their components — the accessibility and compliance project, and therefore the CMS upgrade or migration. this is often yet one more great example of why it’s so important to involve accessibility early within the SDLC also . It’s entirely possible for a CMS to figure perfectly for the remainder of the organization while being fundamentally broken for accessibility specialists.
By splitting the projects — and even shelving the accessibility project until the CMS is addressed , makes it far easier for product owners.
In this final chapter we explore the subsequent risks and pitfalls and show you to avoid them, which include:
- Alienating your existing users
- Legal ramifications of creating an error / inaction
- Failing to style a standard design language
- Failing to account for the entire cost of ownership of one- off costs
- Trying to force every become one project
