Accessibility Best Practices for WCAG Compliance
We design our Consent Management Platform (CMP) components to meet WCAG 2.1 Level AA accessibility standards by default. However, when you apply custom styles—especially using custom CSS—there’s a risk of unintentionally introducing accessibility issues.
This guide outlines best practices tailored for both non-technical and technical users to help ensure your customized notice remains compliant.
Didomi is not an accessibility expert and cannot provide specific accessibility advice. The non-exhaustive information on this page is for general awareness only and is intended to help you identify common issues and get started. For a reliable evaluation and remediation of accessibility concerns, please consult a qualified accessibility partner.
👤 For Non-Technical Users
These are general recommendations for anyone adjusting settings via the Didomi Console or branding options without writing code or CSS.
✅ Use High Contrast Colors
Choose text and background colors with sufficient contrast:
- Normal text: 4.5:1 contrast ratio
- Large text (18pt or 14pt bold): 3:1 contrast ratio
Use free tools like WebAIM Contrast Checker to test.
✅ Keep the Font Legible
Avoid overly decorative fonts. Use readable, sans-serif fonts (e.g., Arial, Helvetica). Ensure font size is at least 16px for body text.
✅ Test with Keyboard Only
Try navigating your notice using just the Tab and Enter keys. All buttons and options should be reachable and actionable this way.
✅ Make it Mobile Friendly
Make sure your notice displays clearly on small screens. Text shouldn’t be cut off or too small to read.
✅ Group and Label Options Clearly
Use descriptive labels for purposes and vendors. Avoid vague terms like “Option 1” or “Click Here.”
🧑💻 For Technical Users & Developers
If you’re applying custom CSS or developing integrations, you must take extra care to preserve accessibility.
🎨 1. Maintain Color Contrast
Avoid using CSS that changes colors without checking contrast. Example:
/* BAD: May create poor contrast */
.notice-text {
color: #999;
background-color: #fff;
}
Fix: Test color pairs for WCAG compliance before applying them.
⌨️ 2. Preserve Focus Styles
Don’t remove focus outlines used for keyboard navigation.
/* BAD: Removes focus indication */
button:focus {
outline: none;
}
Fix:
Instead of removing it, customize it for your brand:
button:focus {
outline: 2px solid #005fcc;
outline-offset: 2px;
}
🧭 3. Use Semantic HTML
Avoid replacing semantic elements with non-standard containers (e.g., <div> instead of <button>). If you must use custom elements, add ARIA roles and labels appropriately.
🧪 4. Use Testing Tools
Validate your final implementation with:
- Lighthouse (in Chrome DevTools)
- Axe DevTools
- NVDA or VoiceOver for screen reader testing
- Keyboard-only navigation
🚨 5. Avoid Hiding Essential Elements
If you use CSS to hide components (e.g., modals, overlays), ensure they are only hidden visually (display: none) and not completely removed from the accessibility tree unless intended.
📋 Quick Developer Checklist
| Item | OK? |
|---|---|
| Sufficient color contrast | ☐ |
| Focus styles preserved | ☐ |
| Uses semantic HTML or ARIA | ☐ |
| Fully keyboard-navigable | ☐ |
| Responsive on mobile | ☐ |
| Tested with screen readers/tools | ☐ |