Colour-Blind Friendly Palettes: Beyond Basic Contrast
Learn how to select and combine colours that work for all types of colour blindness. We’ve researched the science and tested real palettes.
Read ArticleBuilding Inclusive Design into Your Process
Accessibility isn’t an afterthought. We show how to integrate inclusive design principles from the start — checklists, testing methods, and team workflows that actually work.
Why Accessibility Needs to Start Early
Here’s the thing — if you bolt accessibility onto a design at the end, you’re fighting against every decision you’ve already made. Colors won’t work for colour-blind users. Font sizes are too small. Focus states are missing. It’s not that teams don’t care. They’re just building it in the wrong order.
The best approach? Make it part of your actual design process from day one. Not a separate checklist. Not something you handle in QA. We’re talking about building it into how your team thinks, works, and delivers. You’ll find it actually makes everything better — faster decisions, fewer revisions, designs that work for everyone.
What This Means for Your Team
- Colour-blind friendly palettes from the start
- Font sizing standards built into your design system
- Focus states designed before implementation
- Testing workflows that catch issues early
- Team skills that stick around
The Four-Step Integration Process
This is how teams actually make it work — not theory, but practical steps you can implement this week.
01
Audit Your Current Process
Where does accessibility actually happen right now? Is it in design reviews? During development? QA testing? Most teams can’t answer this. Spend a morning mapping it. You’ll probably find it’s scattered or missing entirely. That’s not a failure — it’s your baseline.
02
Build Design System Standards
Create explicit rules for colour, typography, and interaction. Document them. Make them searchable. Your team should be able to grab a colour palette that works for colour-blindness, font sizes tested for readability, and focus state templates. Put these in your design tool. Make them the default, not the exception.
03
Integrate Testing Into Design Reviews
Don’t wait for development to test accessibility. Use tools like colour-blindness simulators and contrast checkers during design. Show your work in greyscale. Check focus states on keyboard navigation. It takes maybe 10 minutes per design. You’ll catch 80% of issues before code is written.
04
Train Your Team (Actually)
One workshop isn’t training. People need to practice. Build accessibility knowledge into your weekly or bi-weekly design sync. Share one colour palette or technique each time. Rotate who presents. It sticks better when teammates teach teammates.
Colour-Blind Friendly Palettes: The Real Version
About 1 in 12 men and 1 in 200 women have some form of colour blindness. That’s not a small edge case. It’s your audience. The problem isn’t that you can’t use colour — it’s that you can’t use colour alone to communicate information.
Your design system needs palettes tested for different types of colour blindness. Deuteranopia (red-green), protanopia (red-green variant), and tritanopia (blue-yellow). Tools like Sim Daltonism let you preview your work in real-time. Most teams spend 2-3 hours building tested palettes once. Then you’ve got them forever.
Don’t just add contrast ratios. Use patterns, icons, or text labels alongside colour. A chart that’s red versus green also needs a different texture or a label. A button that changes colour on hover also needs an outline or underline. Colour is one layer of information, not the only layer.
Font Size Standards That Actually Work
WCAG 2.1 guidelines say body text should be at least 16px. But “should be” isn’t a design system rule. Your team needs numbers. 16px for body, 18px for larger text blocks, 14px minimum for secondary information. Put these in your design tokens. Make them mandatory.
Line height matters too. For body text, aim for 1.5 or higher. That 50% extra space between lines makes reading easier for everyone — especially people with dyslexia or low vision. Tighter line-height (1.2) works for headings. The bigger the text, the less space you need between lines.
Letter spacing? Most designs are fine with normal spacing. But if you’re using all-caps text or a very tight font, add a bit more space. It’s not about perfection. It’s about readability for people with different vision abilities. Your designer should be able to pull tested typography straight from the design system and be done.
Focus States: Design Them, Don’t Inherit Them
Keyboard users need to see where they are. That blue outline browsers add by default? It’s there for a reason. But most designs remove it and don’t replace it with anything. Now you’ve got invisible buttons for keyboard navigation.
Your design system needs explicit focus state styles. A thick outline, a background colour change, or an underline — whatever fits your brand. The key is contrast and visibility. If someone’s navigating with just a keyboard, they need to see every interactive element light up when it gets focus. Design this. Prototype it. Show it to your team. Then build it.
Test it yourself. Unplug your mouse. Navigate your whole design with Tab, Shift+Tab, and Enter. Where do you lose track of where you are? That’s where you need stronger focus states. Aim for at least a 3:1 contrast ratio on the focus indicator itself.
Your Accessibility Checklist: Design Phase
Use this during design reviews. It’s not exhaustive. It’s practical — things you can actually check in 10 minutes.
Colour & Contrast
- Text contrast is at least 4.5:1 (WCAG AA)
- Colour isn’t the only way to communicate information
- Palette tested in colour-blindness simulator
- Patterns or icons used alongside colour
Typography
- Body text is at least 16px
- Line-height is 1.5 or higher
- Font is readable (not decorative for body text)
- No text in all-caps for large blocks
Interaction & Focus
- All buttons have visible focus states
- Links are underlined or clearly distinguishable
- Interactive elements are at least 44×44 pixels
- Hover and focus states are consistent
Layout & Navigation
- Keyboard navigation order is logical
- No keyboard traps
- Spacing between elements is adequate
- Text is readable on small screens
Making It Stick: Workflow Changes That Work
Checklists are useful. But they’re not enough. You need accessibility built into your actual workflow. Here’s what we’ve seen work:
In design tools: Create accessibility-focused components in Figma, Sketch, or Adobe XD. Colour palettes tested for colour-blindness. Typography styles with proper sizing and line-height. Focus state variants. Make these the default. When someone creates a new button, they’re not choosing — they’re using the accessible component.
In design reviews: Add a 5-minute accessibility check. Pull up a contrast checker. Run the design through a colour-blindness simulator. Show focus states. It becomes part of the conversation, not an add-on.
In handoff: Document accessibility requirements alongside design specs. “This button needs a visible focus state with 3:1 contrast minimum.” “These colours need to work in protanopia mode.” Make it part of the development brief, not a surprise later.
Implementation: Where Design Meets Code
Designer to Developer Handoff
Don’t just pass designs. Document the accessibility requirements. Show the focus state design. Specify the exact colour palette tested for colour-blindness. Explain why a button is 44 pixels tall (it’s the minimum touch target). Developers who understand the “why” build it better.
Testing Before Launch
Use tools like WAVE or Lighthouse to catch issues. But also test manually. Tab through the interface. Turn off JavaScript. Zoom to 200%. Does it still work? These aren’t perfect tests, but they catch real problems before users find them.
Iteration Based on Feedback
Launch and listen. If you’re building for a diverse audience, you’ll hear from people about what works and what doesn’t. Contrast too low? Font size too small? Focus states hard to see? These are quick fixes. Iterate based on real user feedback.
Maintenance and Updates
Accessibility isn’t one-time work. When you update the design, update the accessibility standards too. New colours? Test them. New typography? Check the sizing. Keep your design system and accessibility practices in sync.
The Payoff: Why This Matters Beyond Compliance
Yes, you’re meeting WCAG guidelines. That’s important. But the real benefit? You’re designing better for everyone. Larger fonts are easier to read. High contrast helps people with low vision and people using devices in bright sunlight. Focus states help keyboard users and people using screen readers. Good colour choices work for colour-blind users and print better.
Your team also gets faster. When accessibility is built in, there’s less rework. Fewer “we need to fix the contrast” moments in QA. Designers and developers work from the same standards. The handoff is smoother. You launch faster and with fewer issues.
Start this week. Pick one thing — maybe colour palettes. Test them. Document them. Use them in your next project. Then add focus states. Then typography standards. You don’t need to do everything at once. You just need to start building accessibility into your process instead of bolting it on at the end. Your users — all of them — will notice the difference.
Ready to make accessibility part of your team’s process?
Explore More ResourcesRelated Articles
Disclaimer
This article provides educational information about inclusive design principles and accessibility standards. While we’ve referenced WCAG 2.1 guidelines and best practices, accessibility requirements may vary based on your specific context, industry regulations, and location. We recommend consulting with accessibility specialists and conducting user testing with people with diverse abilities to ensure your designs meet the needs of your actual audience. This information is intended to inform your design process — not replace professional accessibility audits or legal compliance advice.