How to Make Accessibility "Stick"
A simple, bold graphic showing three square icons side by side. The first icon on the left is a green checkmark labeled "YES" below it. The middle icon is a red “X” labeled "NO." The icon on the right is a yellow question mark labeled "MAYBE."
Accessibility leaders are frequently on the defensive. We're brought into the room after the design is finished, the code is written, prototyped, or in beta. Every accessibility leader’s nightmare is to find out about inaccessible products by way of litigation after the inaccessible product is already live. With the pressure to ensure WCAG conformance, reduce legal risk, and protect disabled users from harm, it's easy to default to one word: no. No to moving carousels. No to infinite scroll. No to animation. No to anything that sounds like a lawsuit waiting to happen.
It might seem like a great short-term solution, but "no" doesn't scale.
“No” makes accessibility professionals look like blockers.
“No” generates hostility and an “us vs. them” mentality
“No” undermines the message that accessibility is for everyone, and reframes it as purely a legal or compliance issue.
There’s a better way. Accessibility teams need to move from "no" to "yes, but" — a constructive, conditional yes that acknowledges design intent while insisting on WCAG conformance and inclusive user experience. Here’s how.
Say Yes, But: A Constructive Alternative
“Yes, but” means acknowledging the team’s goal and design direction while attaching clear, non-negotiable requirements that meet accessibility standards. It moves from prohibition to conditional enablement.
“Yes, but” is not:
“Yes, do whatever you want.”
“Yes, this fails WCAG, but we’ll let it slide.”
“Yes, but” is:
“Yes, you can use this pattern, but it needs to work for everyone.”
“Yes, you can do this if the following conditions are met.”
“I will help you make this work if you have the budget and time to do it right.”
Common Scenarios and “Yes, But” Responses
1. Carousels
Team asks: “Can we use a moving carousel to showcase featured products?”
Old answer: “No. Carousels are bad for accessibility.”
Yes, but response:
“Yes, you can use a moving carousel, but you must follow WCAG 2.2 and make sure it:
Doesn’t auto-advance without user consent (WCAG 2.2.2 Pause, Stop, Hide)
Has clear previous/next buttons with accessible names and roles (WCAG 4.1.2 Name, Role, Value)
Includes visible and programmatically exposed indicators for which slide is active (WCAG 1.3.1 Info and Relationships)
Supports keyboard navigation and screen reader announcements for all content (WCAG 2.1.1 Keyboard, 1.3.2 Meaningful Sequence)
Has descriptions for all informative graphics
If you can’t meet these, then we’ll need to rethink the design.”
2. Hover Menus
Team asks: “We want to use a hover-based mega menu.”
Old answer: “No. Hover menus don’t work for keyboard users.”
Yes, but response:
“Yes, hover menus can be used, but they must:
Be fully operable with a keyboard (WCAG 2.1.1)
Stay open while a user moves their pointer or focus within the menu
Not trap focus or disappear if someone accidentally overshoots
Have visible focus indicators (WCAG 2.4.7)
This might require JavaScript beyond default HTML behavior. If that’s not in scope, we must use a simpler menu pattern.”
3. Infinite Scroll
Team asks: “Can we implement infinite scroll for our content feed?”
Old answer: “No. It breaks keyboard and screen reader navigation.”
Yes, but response:
“Yes, you can use infinite scroll, but you must:
Provide a method to load more content on user request (WCAG 2.2.2 Pause, Stop, Hide)
Maintain logical focus order and avoid moving keyboard focus unexpectedly (WCAG 2.4.3 Focus Order)
Announce new content in a way that makes sense to screen readers (WCAG 4.1.3 Status Messages)
We also need to test it with actual assistive technology before launch.”
Why “No” Is the Wrong Default
1. “No” creates friction.
Developers and designers want to build things. Telling them “no” often leads to workarounds, resentment, or delay. It turns accessibility into the villain of innovation instead of a partner in it.
2. “No” doesn’t educate.
Saying “no” without explaining the why and how deprives the team of a learning opportunity. It solves the immediate ask, but it doesn’t raise the organization’s accessibility IQ.
3. “No” is easy to dismiss.
Just like toddlers, the more frequently “no” is used, the more easily it can be ignored. This is especially true when business priorities or deadlines escalate.
Guidelines for Making “Yes, But” Work
1. Lead with understanding.
Acknowledge why the team wants the feature. “I see how this could help users explore your content more efficiently,” softens the transition to the conditions that follow.
2. Reference specific WCAG criteria.
Ground your “but” in standards. This demonstrates that your request is not just one person’s opinion.
3. Provide tested alternatives or patterns.
Don’t stop at identifying problems. Offer a way forward. Link to accessible design system components, sample code, or sandbox prototypes.
4. Set accessibility acceptance criteria in the story.
Include “Definition of Done” accessibility requirements in the user story so there’s no ambiguity. “Carousel must be keyboard operable, announce new items to screen readers, and have pause controls.”
5. Pair reviews with training.
Turn each “yes, but” into a micro-training moment. Over time, designers and developers will learn how to anticipate your conditions and proactively build for them.
What Happens When You Shift the Default?
Better relationships: People stop looking forward to trips to the dentist as a way to avoid dreading accessibility reviews. They stop looping you in late or working around you. Instead, they come earlier and treat you like a partner.
More consistency: When you specify exactly how to meet requirements, you improve implementation quality and reduce variance between teams and products.
Increased organizational maturity: Teams begin to internalize accessibility, integrate it into their processes, and anticipate requirements. “Will this pass?” becomes “How do we do this accessibly from the start?”
When You Still Need to Say No
There are cases where “no” is still the right answer:
Legal or regulatory violations that cannot be mitigated. I’m sorry if your web views inside your native apps don’t re-orient after a device has been rotated when the user is on your California Consumer Privacy Act notice page. Unfortunately, that’s a clear violation of CCPA requirements.
Inherent discriminatory design decisions. This would include things like providing a user with only one sense or channel to complete a task, or an intentional lack of keyboard access.
Budget or timeline constraints that prevent any form of accessible implementation
Even in these cases, explain why it’s a hard stop and offer alternatives that achieve the same business goals in a compliant way.
Final Thoughts
"Yes, but" reframes accessibility from an obstructive function to a collaborative process. It supports innovation while upholding user rights. It changes how others see your role and how you show up in the room.
Stop being the “no” person. Be the person who says, “Yes, you can — if you do it right.”
That’s how you make accessibility stick. That’s how you move the needle forward. That’s how you win trust, which is the most critical thing in business.
Thank you for this clear thinking (and dare I say, caring) article. Your work is work toward a better world!