Then, everything changed. I began to approach accessibility not as a series of requirements, but as a core design principle—and the Web Content Accessibility Guidelines (WCAG) 2.2 became my north star. It didn’t just improve my final product; it fundamentally changed how I think about and execute my design process.
This post is a case study on how adopting WCAG 2.2 as a foundation, rather than a final step, transformed my design workflow for the better.
1. The Shift from “Aesthetic” to “Structured” Design
Before WCAG 2.2, my design process often started with a visual-first approach. I’d focus on an appealing layout, colors, and typography, and then try to fit the functionality into that aesthetic.
WCAG 2.2 forced me to reverse that thinking. Its emphasis on a logical, structured experience meant that my design process now begins with the content and information architecture. I focus on creating a clear hierarchy, structured headings, and predictable navigation, which are not only crucial for screen reader users but also make the product more intuitive for everyone. This shift from “make it look good” to “make it work well” resulted in a stronger, more robust user experience from the very first wireframe.
2. The Power of Early-Stage Collaboration
I used to present a near-final design to developers and content writers. This often led to costly, last-minute changes when they pointed out accessibility or technical issues.
By adopting WCAG 2.2, accessibility became a shared responsibility. The guidelines forced me to collaborate with my team much earlier in the process.
With Developers: I now collaborate with developers from the very beginning, ensuring that interactive elements, animations, and new components can be built accessibly and efficiently.
With Content Writers: I work with content writers to ensure that all copy is clear, concise, and written with an accessible tone. We also ensure that image alt-text is a priority, not an afterthought.
This early collaboration eliminates friction and saves time and money in the long run.
3. Moving from “Checklist” to “Continuous Improvement”
WCAG 2.2 is a living document, and its guidelines are not a simple checklist. My workflow now includes a continuous cycle of auditing and improvement.
Design Audits: As a designer, I run regular audits on my prototypes using automated tools and manual checks. This is a critical habit that ensures accessibility is not lost as the design evolves.
User Feedback: The most valuable feedback comes from real users. My process now includes usability testing with individuals who use screen readers, keyboard navigation, or other assistive technologies. This direct feedback provides invaluable insights that no automated tool can replicate.
The Results: A Better Process, A Better Product
By integrating WCAG 2.2 into my design workflow, the entire process became more thoughtful, collaborative, and intentional. The results were clear:
Fewer Revisions: With accessibility and structure as a foundation, late-stage design and development revisions were drastically reduced.
Improved User Experience: The designs became more intuitive and easier to use for everyone, not just those with specific needs.
Professional Growth: My skills expanded from just visual design to a deeper understanding of user behavior, technical constraints, and collaborative problem-solving.
