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 | ☐ |