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