How does CCM19 meet the requirements of WCAG?
Clear orientation
Logical and intuitive structure
The clearly defined tab order and easily recognizable focus points enable effortless navigation so that users always keep their bearings.
Screen reader compatibility
Optimized for screen reader use
The CCM19 cookie banner supports all common screen readers as well as the required ARIA standards to ensure smooth and accessible navigation.
Keyboard navigation
Convenient control via keyboard
All functions and areas of the cookie banner are fully and easily accessible via the keyboard, even without a mouse - for an accessible user experience.
Optimized colour display
High-contrast design according to WCAG
CCM19 meets the contrast requirements of WCAG (at least 4.5:1) so that texts and buttons are optimally legible for people with visual impairments.
Flexible scaling
Individually customizable display
The cookie banner remains fully operable even when enlarged by up to 200% without losing content - perfect for users with visual impairments.
Comprehensible language
Clear and simply formulated content
All texts in the cookie banner are deliberately written in simple and understandable language so that users can easily grasp the information regardless of their previous knowledge.
CCM19 already helps 210.173 websites to comply with GDPR, TDDDG & Co.
BFSG-compliant through implementation of the WCAG guidelines
WCAG as the basis for BFSG compliance
The CCM19 Cookie Banner has been developed to meet the requirements of the German Accessibility Strengthening Act (BFSG) by consistently taking the international WCAG guidelines into account. This allows you to easily and reliably meet legal accessibility requirements.
Easy to integrate and ready to use
With the intuitive setup wizard, you can easily integrate the CCM19 cookie banner into your website - without any additional technical hurdles. This ensures that your website is designed to be accessible in accordance with WCAG and is also BFSG-compliant.
Targeted support for legal security
CCM19 actively supports you in making your cookie banner accessible and WCAG-compliant so that you can meet the requirements of the BFSG in a legally compliant manner - without any additional effort.
WCAG-compliant and legally compliant - consent management with CCM19
CCM19 also enables you to implement comprehensive consent management, including
Creating transparency for consent
With CCM19 Consent Management, you can reliably and transparently document the consent of your users - clearly structured and traceable at all times. This ensures that you remain legally compliant with the GDPR and WCAG guidelines at all times.
Regular check of GDPR compliance
An automatic scanner regularly checks whether your website continues to meet the current requirements of the GDPR. This ensures continuous legal certainty.
Manage all settings clearly
CCM19 bundles all consent management functions in one place. This saves time, reduces complexity and ensures that your website always meets the latest data protection and accessibility requirements.
Further advantages of CCM19
Optimum loading speed
The CCM19 cookie banner is lean and performance-optimized so that your website loads at lightning speed. Your visitors benefit from a smooth user experience.
Professional support
Our experienced support team is available to answer all your questions about the cookie banner by phone, email and chat - competent, friendly and quickly accessible.
GDPR and BFSG compliant
The CCM19 cookie banner complies with the current legal requirements of the GDPR and BFSG at all times. This means you always provide your users with transparent and legally compliant information.
Features for an accessible cookie banner
WCAG conformity with CCM19: Overview of all fulfilled criteria
In the following table, you can see at a glance how the CCM19 Cookie Banner specifically fulfills the requirements of the Web Content Accessibility Guidelines (WCAG 2.1).
Criteria that are not relevant are marked accordingly.
| WCAG section | Description | Relevance for CCM19 |
|---|---|---|
| 1.1 Text Alternatives | ||
| 1.1.1 Non-text content | All non-text content has a text alternative: - All input fields have a label or aria-label - All purely decorative elements are marked so that they are ignored by screen readers (aria-hidden="true") - Everything that cannot be displayed as text has at least a short description of what can be seen or heard. | ✅ |
| 1.2 Time-based media | ||
| 1.2.1 Audio-only/Video-only (Prerecorded) | Audio: There is an alternative display for audio content for the deaf. Video: There is a descriptive audio track or an alternative representation for the blind. | Not relevant |
| 1.2.2 Captions (Prerecorded) | Videos have subtitles. | Not relevant |
| 1.2.3 Audio Description or Media Alternative (Prerecorded) | Videos contain a descriptive audio track or an alternative textual representation. | Not relevant |
| 1.2.4 Captions (Live) | There are live captions for live videos with sound. | Not relevant |
| 1.2.5 Audio Description (Prerecorded) | There is an audio description for video content. | Not relevant |
| 1.2.6 Sign Language (Prerecorded) | Optional: Sign language videos for audio content are available. | Not relevant |
| 1.3 Adaptable | ||
| 1.3.1 Info and Relationships | Information, structures and relationships resulting from the layout are programmatically recognizable (e.g. via for attributes, aria-labelledby, aria-controls) or available in text form. | ✅ |
| 1.3.2 Meaningful sequence | The meaningful reading sequence is recognizable for screen readers. | ✅ |
| 1.3.3 Sensory characteristics | Instructions are not based solely on appearance (shape, position, color). | ✅ |
| 1.3.4 Orientation | No fixed restriction to portrait or landscape format, unless absolutely necessary and justified. | ✅ |
| 1.3.5 Identify input purpose | The purpose of input fields can be identified programmatically (e.g. with type and autocomplete attribute). | ✅ |
| 1.3.6 Identify Purpose (optional, level AAA) | The purpose of all UI elements, icons and regions can be identified programmatically. | ✅ |
| 1.4 Distinguishable | ||
| 1.4.1 Use of color | Color must never be the only feature used to convey information. Alternatives are, for example, differences in brightness or shapes. | ✅ |
| 1.4.2 Audio control | For audio that plays automatically for longer than 3 seconds, there is a pause, stop function or volume control. | not relevant |
| 1.4.3 Contrast (Minimum) | The minimum contrast for (continuous) text is 4.5:1. For large text (headings etc., from 18pt or 14pt bold): 3:1 Deactivated inputs/buttons, logos and purely decorative elements have no contrast requirement. | ✅ |
| 1.4.4 Resize text | Text can be enlarged by up to 200 % without loss of function. | ✅ |
| 1.4.5 Images of text | Images containing text are avoided unless absolutely necessary or the text is generated from user input. | ✅ |
| 1.4.6 Contrast (Enhanced) (optional, level AAA) | Contrast ratio is 7:1 for (continuous) text and 4.5:1 for large text. | ✅ |
| 1.4.7 Low or no background audio | (is fulfilled) | not relevant |
| 1.4.8 Visual Presentation (optional, level AAA) | Can be set so that the text is displayed as follows: - Foreground and background color selectable - No more than 80 characters in one line - No justification - Line spacing at least 1.5 - Paragraph spacing 1.5x larger than line spacing - Text can be enlarged up to 200% without having to scroll horizontally (on standard displays in full screen) | ✅ |
| 1.4.9 Images of Text (No Exception) (optional, level AAA) | see 1.4.5 | ✅ |
| 1.4.10 Reflow | The page is responsive → All content is accessible at all screen sizes and no scrolling in two dimensions (vertical+horizontal) is necessary... for vertical content with a width of 320 CSS pixels for horizontal content with a height of 256 CSS pixels unless it is absolutely and justifiably necessary for 2-dimensionally displayed items. | ✅ |
| 1.4.11 Non-text contrast | UI elements (inputs, buttons, etc.) have a contrast ratio of at least 3:1, unless they are deactivated or the standard browser input is used. Graphics that are important for the content also have a minimum contrast of 3:1. | ✅ |
| 1.4.12 Text spacing | If the following text formatting is enforced by the browser, the page will continue to work without problems: - line height of 1.5 - paragraph spacing: 2 x font size - letter spacing: 0.12 x font size - word spacing: 0.16 x font size | ✅ |
| 1.4.13 Content on hover or focus | If content is added/removed by hovering/focusing an element (overlays, popovers), then: - these can be closed (dismissible), unless they never cover anything else or communicate an input error, - the cursor can be moved over the popover without it disappearing, - the content remains visible until it is closed, the focus is removed, or the information is no longer valid. | ✅ |
| 2.1 Keyboard Accessible | ||
| 2.1.1 Keyboard | All functionality is accessible and controllable with the keyboard (except impossible for the existing interface, e.g. handwritten signature with the mouse). The functionality does not depend on a certain typing speed. | ✅ |
| 2.1.2 No keyboard trap | The keyboard focus is not locked. If it is necessary for a function and this is not possible with the normal keys (Tab etc.), the way to remove the focus is possible with the keyboard and is described on the page. | ✅ |
| 2.1.3 Keyboard (No Exception) (optional, level AAA) | see 2.1.1 | ✅ |
| 2.1.4 Character key shortcuts | If there are keyboard shortcuts that only use normal (printable) keys without modifiers (Ctrl, Alt, ...), these are either: - can be switched off, - can be switched to Ctrl, Alt, ... + the key, - or only active while the element in question has the focus. | ✅ |
| 2.2 Enough Time | ||
| 2.2.1 Timing Adjustable (optional, level AAA) | If there are time limits (<20h), these can either be switched off, adjusted up to at least 10x or extended. | ✅ |
| 2.2.2 Pause, stop, hide | Flashing, automatically moving or scrolling content longer than 5s can be paused, stopped or hidden. Automatically updating content that is displayed in parallel with other content can be paused, stopped or hidden or the update frequency can be set. | ✅ |
| 2.2.3 No timing | No time limits or dependencies on the user's reaction time. | ✅ |
| 2.2.4 Interruptions (optional, level AAA) | Interruptions can be delayed or suppressed by the user, except for emergency messages. | ✅ |
| 2.2.5 Re-authenticating (optional, level AAA) | If the session expires, the user can continue the activity without losing data. | ✅ |
| 2.2.6 Timeouts (optional, level AAA) | Users are warned and informed about the time limit if inactivity can lead to data loss, unless the data is held for more than 20 h. | ✅ |
| 2.3 Seizures and Physical Reactions | ||
| 2.3.1 Three Flashes or Below Threshold | Nothing flickers more than 3x per second at more than 300x200 px combined. | ✅ |
| 2.3.2 Three Flashes (optional, level AAA) | Nothing flickers more than 3x per second. | ✅ |
| 2.3.3 Animation from Interactions (optional, level AAA) | All unnecessary motion animations can be switched off. Motion animations: Movements and size changes, not just color change or fade out. | ✅ |
| 2.4 Navigable | ||
| 2.4.1 Bypass blocks | Blocks that are repeated on several pages (header, navigation, etc.) can be skipped with a mechanism for screen readers - for example via navigation links, ARIA landmarks, sections with headings or drop-down menus. | ✅ |
| 2.4.2 Page titled | The page has a meaningful title. | ✅ |
| 2.4.3 Focus order | The tab focus order makes sense. | ✅ |
| 2.4.4 Link Purpose (In Context) | The purpose of a link is recognizable from the link text (or at most together with the surrounding text or table headings). | ✅ |
| 2.4.5 Multiple ways | There is more than one way to reach a page (exception: e.g. in wizards or order confirmation pages). Can be implemented with "Links to related pages", table of contents, sitemap or search function. | ✅ |
| 2.4.6 Headings and labels | There are descriptive headings and labels. | ✅ |
| 2.4.7 Focus Visible | The keyboard focus is always visible when you scroll. | ✅ |
| 2.4.8 Location (optional, level AAA) | The current position on the website (e.g. via breadcrumbs) is visible. | ✅ |
| 2.4.9 Link Purpose (Link Only) (optional, level AAA) | The purpose of a link is always recognizable from the link text, unless it is unclear even for people without disabilities. | ✅ |
| 2.4.10 Section headings (optional, level AAA) | Section headings are used to organize the content. | ✅ |
| 2.5 Input Modalities | ||
| 2.5.1 Pointer gestures | All interactions with movement gestures where not only the start and end points are important or several fingers are required can also be carried out with a simpler gesture or mouse clicks. | ✅ |
| 2.5.2 Pointer Cancellation | An action is not completed on mousedown, but only when the mouse is released over the element and can be canceled or undone. | ✅ |
| 2.5.3 Label in name | The ARIA label contains the visible label/button text. | ✅ |
| 2.5.4 Motion Actuation | All functions that are triggered by moving/shaking/rotating the device can alternatively be controlled in the UI and the reaction to movements can be switched off. | not relevant |
| 2.5.5 Target size (optional, level AAA) | Clickable elements are at least 44 × 44 CSS pixels in size or there is a correspondingly large alternative - with the exception of links in continuous text. | ✅ |
| 2.5.6 Concurrent input mechanisms (optional, level AAA) | The website does not unnecessarily restrict the input method. Touch, mouse and keyboard work equally well, and it is easy to switch between them. | ✅ |
| 3.1 Readable | ||
| 3.1.1 Language of page | The main language of the page is programmatically recognizable. | ✅ |
| 3.1.2 Language of Parts | Language changes in individual sections or words are marked programmatically. Exceptions: Technical terms, proper names, etc. | ✅ |
| 3.1.3 Unusual Words (optional, level AAA) | For unusual words, there is a mechanism with an explanation(<dl>, <dfn>, glossary, etc.). | ✅ |
| 3.1.4 Abbreviations (optional, level AAA) | There is a mechanism for abbreviations with the written-out form or meaning. | ✅ |
| 3.1.5 Reading level (optional, level AAA) | For more complicated language than main school level, there are explanatory texts or a simpler alternative. | ✅ |
| 3.1.6 Pronunciation (optional, level AAA) | If the pronunciation of a word depends on the context or the meaning is unclear without pronunciation, the pronunciation can be identified. | ✅ |
| 3.2 Predictable | ||
| 3.2.1 On Focus | Only setting the focus on an element does not trigger a page change or similar large-scale intervention in the page. | ✅ |
| 3.2.2 On Input | Only changing the value of an input element does not trigger a page change or focus change - unless the user has been informed beforehand. | ✅ |
| 3.2.3 Consistent navigation | Navigation is consistent on the website. The order of the menu items remains the same unless the user intentionally changes it. | ✅ |
| 3.2.4 Consistent identification | Elements with the same function are consistently named and recognizable. | ✅ |
| 3.2.5 Change on request (optional, level AAA) | Page changes and similar large-scale interventions (as well as focus shifts) are only triggered at the user's request or can be deactivated. | ✅ |
| 3.3 Input assistance | ||
| 3.3.1 Error identification | In the event of input errors, the input field with the error is identified and the problem is described. | ✅ |
| 3.3.2 Labels or instructions | Labels or instructions assist with input. | ✅ |
| 3.3.3 Error suggestion | If errors are detected, corrections are suggested (if safely possible). | ✅ |
| 3.3.4 Error prevention (legal, financial, data) | Legally or financially relevant entries can be reversed or are checked. | ✅ |
| 3.3.5 Help (optional, level AAA) | Context-related help is available. | ✅ |
| 3.3.6 Error Prevention (All) (optional, level AAA) | For all user entries, the entry can either be undone, is checked for errors (with correction option) or is confirmed with a review of the changes. | ✅ |
| 4.1 Compatible | ||
| 4.1.1 Parsing | The HTML is valid, IDs are unique. | ✅ |
| 4.1.2 Name, role, value | Name/label and role/function are programmatically recognizable for non-standard form elements. ARIA states and properties are set. | ✅ |
| 4.1.3 Status messages | Live status messages can be recognized as such programmatically. | ✅ |
Frequently asked questions
Have we piqued your interest?
Would you also like to make your website barrier-free and need a BFSG and GDPR-compliant cookie banner, but still have questions about the contract design or the technical capabilities of the system? No problem - we will be happy to help you! Simply fill in all the fields marked with an asterisk (*) and we will get back to you as soon as possible. We look forward to your inquiry!
If you have any questions, you can of course also contact us by phone, e-mail or via our contact form.
Tel: +49 228 536 637 26
E-mail: info@ccm19.de