3 Key Ingredients for the Efficient Implementation of Accessible Websites

I'm a developer who works for a digital agency, a company whose job (among other things) is to build web experiences for other companies.

Adherence to the Web Content Accessibility Guidelines (WCAG) for new websites is now mandated by law. Client requests to efficiently and cost-effectively implement and test for accessibility guideline compliance in my line of work are increasingly common. For experiences designed and developed at digital agencies we can do this in three ways:

1) Ensure the statement of work correctly articulates which guidelines we are supporting,
2) Design and develop to those guidelines, and
3) Test domain-specific guidelines for compliance at each stage of the project.

“Just fix accessibility issues later!”

This third way we can ensure accessibility is built in is critical. It is a misconception at many agencies that all accessibility-related defects can be fixed at a code level at the end of the development phase. This is not true. Accessibility defects can be introduced during wireframe phase, visual design phase, and content creation phase. Some of the accessibility issues we find require a designer's input to fix. How do we engage designers to help us fix these issues, and when is the right time to engage them?

Test accessibility compliance at every phase!

An accessibility review should be performed at the end of each project phase. Resulting defects should be fixed before moving on to the next phase. This results in fewer manual test cases required during quality assurance (QA) testing phase, because we can reduce the noise for the QA team by eliminating any manual tests that relate to user experience design and visual design and content. More importantly, the development team will be able to fix any remaining accessibility issue on their own.

What does this mean for your project plan?

Adding additional internal accessibility reviews means that your design cycles will take a bit longer. But the results are worth it! Add this to your project timeline and you will never have to extend your QA and UAT phases to account for unexpected accessibility issues.

Happy developing!

Leave a Reply

Your email address will not be published. Required fields are marked *