Is accessibility stressing you out? You're not alone. Here's how to move forward without paralyzing your teams.
Monday morning, team meeting. The Product Owner announces: “We need to be RGAA compliant for the next sprint.” Awkward silence. The lead developer sighs. You, the designer, can already see the 47 Jira tickets about color contrasts coming.
I've experienced it dozens of times. Accessibility is like recycling: everyone agrees it's important, but no one really knows where to start. And above all, there's the fear that it will slow everything down.
Spoiler: that shouldn't.
Why accessibility freaks you out (and that's normal)
Let's be frank. When we talk about "accessibility," three anxieties come to mind:
- “We’re going to have to redo everything.” Imagine the six months of redesign required to bring your 200 screens into compliance. The budget explodes, the schedule goes off track, and your product manager has a heart attack.
- “It’s too technical, I don’t understand it.” ARIA, AA/AAA compliance levels, screen readers, keyboard navigation… You're being spoken to in a language that sounds more like code than design. You don't even know where to begin.
- “This is going to kill my design.” You've spent three weeks working on this subtle color palette. Now you're being told that your blue #4A90E2 doesn't have enough contrast. You feel like you're going to be forced to use black on white everywhere.
The result? We procrastinate. We tell ourselves "we'll do it later." And "later" never comes.
The truth: You're already doing 50% of the work without even realizing it.
A little experiment. Look at your last mockup and check what you did:
✓ Clear hierarchy with titles and subtitles
✓ Labels visible on your form fields
✓ Buttons with explicit text (not just icons)
✓ Sufficient spacing between clickable elements
✓ Mobile-first mockups
If you checked at least 3 boxes, congratulations: you are already doing accessibilityYou just didn't call it that.
Because here's the secret: Accessibility starts with good design.A clear, logical, predictable design. What helps a blind person also helps your grandmother, a user in a hurry on the subway, or someone browsing your site in the sun.
The methodology that doesn't block production: The 80/20 accessibility rule
At UX-Republic, we've tested many approaches. Which one works best? The 80/20 rule.
20% of the actions cover 80% of the accessibility problems. Here is that 20%:
1. Color contrasts (10 minutes per screen)
The problem : This is THE number 1 source of non-compliance. And it's fixed in 10 minutes flat.
The quick solution:
- Install the Chrome extension “WCAG Color Contrast Checker”
- Test your text/background combinations while you design
Minimum ratio: 4.5:1 for normal text, 3:1 for wide text (18px+) and interface components (example: button) Concrete example : Your blue #4A90E2 on a white background? Ratio 3.4:1. Not compliant. You are moving on to #2F6DB5: Ratio 4.6:1. Compliant. Visual difference? Almost imperceptible.
Pro Tip: Create a "safe" palette from the start. 5 compliant colors that you reuse everywhere. Huge time saver.
2. Alternative texts for the images (2 minutes per image)
The problem : Screen readers cannot see the images. Without alt text, a blind user only hears “image point JPEG”.
The quick solution: Two questions to ask yourself:
- Does the image provide information? → Describe it simply
- Is the image decorative? → Use alt="" (empty, not absent)
Concrete examples :
❌ Bad: alt="photo" ✅ Good: alt=”Graph showing a 32% increase in conversions in January 2026”
❌ Bad: alt=”banniere-hero.jpg” ✅ Good: alt="" (if it's just for decoration)
Pro Tip: Integrate this step into your Figma workflow. Create an "Alt-text" field in your components. The developers will thank you.
3. Keyboard navigation (5-minute test)
The problem : Many users (those with motor disabilities, power users) navigate without a mouse. If you can't do everything with the Tab key, you're hindering their access.
The quick solution: Unplug your mouse. Test your interface only with:
- Tab : to move from one element to another
- Entrance / Area : to click
- arrows : navigate the menus
Are you stuck somewhere? That's where the problem lies.
Real-life example: Burger menu on mobile. You click on it, it opens. But it's impossible to close it using the keyboard (no Esc key supported). Fix: 2 lines of JavaScript.
Pro Tip: Perform this test with every design review. It takes 5 minutes and will save you 90% of navigation problems.
4. Form labels (1 minute per field)
The problem : A placeholder is NOT a label. As soon as you type, it disappears. The screen reader doesn't see it. The user forgets what they were supposed to enter.
The quick solution: A label visible above every field. Always.
Examples:
❌ Bad:
[Enter] business e-mail…____]
The placeholder disappears as soon as you type.
✅ Good:
[____________________]
The label remains visible.
Pro Tip: If you absolutely must keep your placeholder for aesthetic reasons, keep the label too. But the label must be there.
5. Visible focus states (5 minutes for the entire site)
The problem : When navigating with a keyboard, you need to SEE where you are. Many websites remove the browser's default outline (that ugly blue border) without replacing it.
The quick solution: Never delete outline: none without planning for a replacement.
Example of compliant CSS:
button:focus {
outline: 3px solid #2F6DB5;
outline-offset: 2px;
}
Pro Tip: Integrate the focus state into your design system from the start. Same visual treatment as hover, but with an added border.
The “sprint 0” checklist: What we do BEFORE designing
To avoid having to start all over again later, here's what we put in place right from the beginning of the project:
Design-wise:
☐ Accessible color palette validated (contrast OK)
☐ Typography with defined minimum sizes (16px mobile, 14px desktop)
☐ Focus states designed for all interactive components
☐ Alt-text convention documented in the design system
Regarding the process:
☐ Accessibility plugin installed on Figma (e.g., Stark, A11y)
☐ Accessibility checklist integrated into the Definition of Done
☐ Keyboard test included in the validation criteria
Team side:
☐ 1 accessibility contact person (no need for an expert, just someone to lead)
☐ 30 minutes of training for the team (we'll do a Lunch & Learn)
Total setup time? 2 hours.
The benefit? You avoid 3 weeks of corrections at the end of the project.
The myths that are holding you back (and how to debunk them)
Myth 1: “Accessibility is ugly” False. Apple, Airbnb, and Gov.uk comply with RGAA. Nobody finds that ugly.
The real problem? Confusing accessibility with a lack of graphic design. You can have subtle AND compliant design. Myth 2: “It will cost 30% more time” False. If you integrate accessibility from the start, it's 5% max.
The extra cost comes when you have to redo EVERYTHING at the end. Making things accessible retroactively, now that's expensive.
Myth 3: “We don’t have any disabled users anyway” False (and dangerous). 20% of the population has a disability (temporary or permanent). You have affected users, you just don't know it.
And even without a disability: your users might have the sun in their eyes, a broken arm, be on a moving train, be 65 years old and have impaired vision. Accessibility helps them too.
Where to begin (4-week action plan)
You're convinced but don't know where to start? Here's a step-by-step plan:
Week 1: Express Audit (2 hours)
- Take your 5 most used screens
- Test them with the 80/20 checklist (above)
- List the 10 most critical problems
Week 2: Quick wins (4 hours)
- Correct the color contrasts
- Add the missing alt text
- Test keyboard navigation
Week 3: Process (2 hours)
- Integrate accessibility into your Definition of Done
- Install the verification tools
- Brief the team (30 minutes is enough)
Week 4: Consolidation (4 hours)
- Create your accessible color palette
- Document the conventions in the design system
- Schedule a full audit (if necessary)
Total time invested: 12 hoursResult: You cover 80% of accessibility issues from a design perspective.
What we learned by doing this 50 times
Some lessons learned from the field:
- start small Don't aim for full AA compliance overnight. Choose 3 critical screens. Make them accessible. Learn. Then scale up.
- Involve the developers early Accessibility is 50% determined by the code (HTML structure, ARIA). If your developers only discover this at the end of the sprint, it's a disaster.
- Automate what can be automated Integrate automated tests (Axe, Lighthouse) into your CI/CD pipeline. This detects 30% of problems without human effort.
- Test with real users A technical audit is good. But 30 minutes with a screen reader user teaches you 10 times more.
The resources we actually use
No long list. Here are the 5 tools/resources we use every week:
Tools:
- Stark (Figma plugin): Contrast check + color blindness simulation
- WAVE (Chrome extension): Quick page audit
- Axe DevTools (browser extension): Accessibility tests in development
Resources:
- RGAA 4.1 (Official French reference): The ultimate source, a bit dry but complete
- Web Access : Accessibility guidelines by component, super handy
And what if we really can't do everything?
Let's be realistic. Sometimes, the budget or the schedule doesn't allow for fixing everything. In that case:
Prioritize by user impact:
- Critical : Blocks an entire process (e.g., a form that cannot be filled out using the keyboard)
- Important Makes it difficult but not impossible (e.g., borderline contrast)
- Supplier Comfort (e.g., alternative text for a decorative image)
And document what is not being done Create an "accessibility debt" backlog. At least it's visible. And you can revisit it iteratively.
Perfect accessibility does not exist. Progressive accessibility does.
To go further without feeling guilty
Accessibility isn't an insurmountable mountain. It's a series of small steps. You don't have to be an expert. You just have to be attentive.
Start with the 80/20 rule. Test it with your keyboard. Check your contrasts. Add labels. In 4 weeks, you'll have already made a huge leap forward.
And if you get stuck, don't hesitate to ask for help. There's a real community ready to share (and they don't judge).
Shall we talk about it in real life? If these topics resonate with you and you'd like to explore them further, we regularly organize sessions on these themes. You can also contact us directly for a quick audit or support with your projects >> chloe.fronty@ux-republic.com.
Laetitia Allais
Digital Accessibility Expert at Smile
