# WCAG 2.1 accessibility 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](https://webaim.org/resources/contrastchecker/) 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 | ☐       |


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.didomi.io/consent-management-platform-cmp/consent-notices/wcag-2.1-accessibility-compliance.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.