Highlights of Accessibility Support
While all criteria are essential and addressed, we want to start by highlighting some topics that are of extra importance given the nature of Cevoid’s offering.Widget Navigation
All Cevoid widgets are built to support keyboard navigation and have tags aligned with WCAG standards.Language
Cevoid widgets are automatically localized with the correct language for the markets available on your workspace. The localization support includes all availability features.Alt. Text (Text Alternatives) for Photo and Video Posts
All posts that are approved automatically receive a descriptive alt. text, which is simultaneously translated for all languages activated on your workspace.- The alt. text and its translation can be adjusted by opening the post and clicking Accessibility.
- The alt. text, in the correct language, is presented together with the post in all UGC widgets automatically.
- The alt. text and its translations are available with the posts fetched through the API.
Captions for Video Posts
Video posts where someone speaks automatically receive captions once approved. The captions are automatically translated for all languages activated on your workspace.- The caption and its translation can be adjusted by opening the post and clicking Accessibility.
- Videos where a song is played will have [Music playing] as a caption.
- Captions can be activated and deactivated in the UGC widgets.
- Captions are off by default in all UGC widgets but will be presented for all video posts once a user, or their browser, activates it on one post.
- The caption, in the correct language, is presented as a layover for videos played in the widget UGC popup.
- The caption and its translations are available with the posts fetched through the API.
Descriptions for Videos Without Captions
Video posts without sound or a meaningful caption automatically receive a summarizing description once approved. The video description is automatically translated for all languages available on your workspace.- Video descriptions are automatically presented, in the correct language, for all UGC widgets.
- The video description and its translations are available with the posts fetched through the API.
Cevoid WCAG Breakdown
Applicable Standards/Guidelines
This breakdown covers the degree of conformance for the following accessibility standards/guidelines:| Standard/Guideline | Included In Summary |
|---|---|
| Web Content Accessibility Guidelines 2.1 | - Level A (Yes) - Level AA (Yes) - Level AAA (No) |
Terms
The terms used in the Conformance Level information are defined as follows:| Conformance Level | Meaning |
|---|---|
| Supports | The functionality of Cevoid’s consumer-facing solutions meets the criterion |
| Partially Supports | Some functionality does not meet the criterion |
| Does Not Support | The majority of the functionality does not meet the criterion |
| Not Applicable | The criterion is not relevant to any of Cevoid’s consumer-facing solutions |
Table 1: Success Criteria, Level A
| Criteria | Conformance Level | Remarks and Explanations | |
|---|---|---|---|
| 1.1.1 Non-text Content (Level A) | All icons, images, and other visuals must have a text description or be hidden from assistive tech if they’re decorative. | Partially Supports | All non-text content is either labeled with meaningful text alternatives (e.g. aria-label, alt) or marked decorative to be ignored by assistive technology. 1. Program widgets are missing contextual alt-texts for images uploaded by the company. |
| 1.2.1 Audio-only and Video-only (Prerecorded) (Level A) | Audio-only needs a text transcript. Video-only needs a description or audio explanation. | Supports | Video-only media is used. If displayed, descriptive text alternatives will be provided. If video includes sound synchronized captions can be activated. If video has no sound a description is provided that describes what’s happening in the video. No audio-only media is present. |
| 1.2.2 Captions (Prerecorded) (Level A) | All prerecorded videos with sound must have captions unless they are just an alternative for written content. | Supports | Prerecorded videos with audio include synchronized captions. |
| 1.2.3 Audio Description or Media Alternative (Prerecorded) (Level A) | Videos with audio must have either a text alternative or an audio description of what’s visually happening. | Supports | Prerecorded synchronized media includes a full text alternative that conveys the equivalent information. |
| 1.3.1 Info and Relationships (Level A) | Visual structure like headings, lists, and tables must also be encoded so assistive tech can understand it. | Supports | Semantic HTML and ARIA roles are used to expose structure and relationships to assistive technologies. |
| 1.3.2 Meaningful Sequence (Level A) | Content must be presented in a logical order, and that order must be recognizable by assistive tech. | Supports | DOM order matches visual presentation and ensures correct reading sequence for assistive tech. |
| 1.3.3 Sensory Characteristics (Level A) | Instructions can’t rely only on things like color, shape, or position (e.g., “Click the red button”). | Supports | Instructions avoid referring only to visual or sensory cues (e.g., “click the button on the left”). |
| 1.4.1 Use of Color (Level A) | Color alone can’t be the only way to show meaning (e.g., don’t just use red to mean “error”). | Supports | Color is not used as the sole method of conveying information or instructions. |
| 1.4.2 Audio Control (Level A) | If audio plays automatically for more than 3 seconds, users must be able to stop or control it separately. | Supports | No audio content plays automatically. If added, a control will be provided to pause or stop playback independently. |
| 2.1.1 Keyboard (Level A) | Everything must be usable with a keyboard only (no mouse required). | Supports | All functionality is operable via keyboard navigation without requiring a mouse. |
| 2.1.2 No Keyboard Trap (Level A) | Users must be able to move focus into and out of all components using the keyboard. | Supports | Keyboard trapping does not take place anywhere other than required (modal windows). |
| 2.1.4 Character Key Shortcuts (Level A 2.1 and 2.2) | If a single key shortcut is active, users must be able to turn it off or modify it. | Supports | Character key shortcuts are not present. |
| 2.2.1 Timing Adjustable (Level A) | If there’s a time limit, users must be able to extend, adjust, or turn it off (unless essential). | Supports | Timeout content capability is not present. |
| 2.2.2 Pause, Stop, Hide (Level A) | For blinking, scrolling, or auto-updating content, users must be able to pause, stop, or hide it. | Supports | Blinking, scrolling, or auto-updating content capability is not present. |
| 2.3.1 Three Flashes or Below Threshold (Level A) | Nothing on screen should flash more than 3 times per second (unless it’s below the seizure risk threshold). | Supports | Flashing content capability is not present. |
| 2.4.1 Bypass Blocks (Level A) | Users must be able to skip repeated content (like menus) to go straight to main content. | Supports | Content blocks are not present. |
| 2.4.2 Page Titled (Level A) | Pages must have clear and descriptive <title> tags. | Supports | Unique page titles are supplied by default. |
| 2.4.3 Focus Order (Level A) | When navigating with the keyboard, focus must move in a logical and meaningful order. | Supports | Focus moves in a logical, expected order when using the keyboard. |
| 2.4.4 Link Purpose (In Context) (Level A) | The purpose of every link must be clear from the link text or its surrounding context. | Supports | The purpose of each link can be determined from the link text. |
| 2.5.1 Pointer Gestures (Level A 2.1 and 2.2) | Complex gestures (like swipe or pinch) must have a simple alternative. | Supports | Simple alternatives are provided. |
| 2.5.2 Pointer Cancellation (Level A 2.1 and 2.2) | Users must be able to cancel pointer actions (like drag/drop) before they are completed. | Supports | Pointer interactions can be canceled before completing the action. |
| 2.5.3 Label in Name (Level A 2.1 and 2.2) | Interactive elements with visual labels must include the visible label in their accessible name. | Supports | Controls, text links, and icon-only controls feature accessible names which match the visual portion. |
| 2.5.4 Motion Actuation (Level A 2.1 and 2.2) | If motion (like shaking the device) triggers an action, there must be another way to do the same thing without moving. | Supports | No motion-based input is required. |
| 3.1.1 Language of Page (Level A) | Each page must define its main language using the lang attribute. | Supports | Default page language (English) is supplied in the head section meta element. |
| 3.2.1 On Focus (Level A) | Focusing on an element (like a form field) should not cause unexpected changes. | Supports | Focusing on components does not trigger context or page changes. |
| 3.2.2 On Input (Level A) | Changing the value of a form input shouldn’t trigger a major change unless clearly warned. | Supports | Input changes do not trigger significant changes without prior notice. |
| 3.2.6 Consistent Help (Level A 2.2 only) | If help is offered, it should be available consistently on every relevant page. | Supports | Help options (if available) are provided consistently across applicable views. |
| 3.3.1 Error Identification (Level A) | Input errors must be clearly indicated, with text descriptions of what’s wrong. | Supports | Errors are clearly indicated with textual descriptions. |
| 3.3.2 Labels or Instructions (Level A) | Forms must include clear labels or instructions for user inputs. | Supports | Form fields include descriptive labels and/or placeholder instructions. |
| 3.3.7 Redundant Entry (Level A 2.2 only) | Users shouldn’t have to enter the same info more than once in a session unless necessary. | Supports | Previously entered information is retained and reused when possible. |
| 4.1.2 Name, Role, Value (Level A) | UI components must expose name, role, and state correctly to assistive tech (e.g., ARIA). | Supports | All custom and native UI elements expose correct name, role, and value using semantic HTML or ARIA. |
Table 2: Success Criteria, Level AA
| Criteria | Explanation | Conformance Level | Remarks and Explanations |
|---|---|---|---|
| 1.2.4 Captions (Live) (Level AA) | Live audio content (like livestreams) must have captions in real-time. | Not Applicable | Live video content capability is not present. |
| 1.2.5 Audio Description (Prerecorded) (Level AA) | Videos with sound must include an audio description track for important visual content. | Supports | Prerecorded video content includes audio descriptions of important visual elements to ensure accessibility for users with visual impairments. |
| 1.3.4 Orientation (Level A 2.1 and 2.2) | Content must work in both portrait and landscape unless a specific orientation is essential. | Supports | Content is responsive and can be used in both portrait and landscape orientations. |
| 1.3.5 Identify Input Purpose (Level A 2.1 and 2.2) | Form fields must have autocomplete attributes so browsers can recognize their purpose. | Supports | Form fields include autocomplete attributes to identify input purpose. |
| 1.4.3 Contrast (Minimum) (Level AA) | Text and images of text must have enough contrast against the background (4.5:1 for normal text). | Partially Supports | 1. Some elements may feature insufficient contrast due to design being modifiable by the company. |
| 1.4.4 Resize text (Level AA) | Text must be resizable up to 200% without losing content or functionality. | Supports | Text resizes up to 200% without loss of content or functionality. |
| 1.4.5 Images of Text (Level AA) | Use real text instead of images for any textual content, unless necessary (e.g., logos). | Supports | Text is displayed using actual text elements, not images. |
| 1.4.10 Reflow (Level A 2.1 and 2.2) | Content should reflow without horizontal scrolling on small screens (up to 320px wide). | Supports | Content is consumable at any viewport size and reflows as required. |
| 1.4.11 Non-text Contrast (Level A 2.1 and 2.2) | UI components (like buttons, inputs, focus indicators) must also meet contrast requirements. | Partially Supports | 1. Focus rings may feature insufficient contrast. 2. Contrast may feature insufficient contrast due to design being modifiable by the company. |
| 1.4.12 Text Spacing (Level A 2.1 and 2.2) | Users should be able to adjust spacing (line height, word/letter spacing) without breaking layout. | Supports | Adjusting text spacing does not break layout or functionality. |
| 1.4.13 Content on Hover or Focus (Level A 2.1 and 2.2) | Any content triggered by hover or focus (like tooltips) must be dismissible, persistent, and hoverable. | Supports | Pointer hover or keyboard focus content triggers persistent content on hover and is dismissible. |
| 2.4.5 Multiple Ways (Level AA) | Provide more than one way to find pages (e.g., menu, search, breadcrumbs). | Supports | Users can navigate using menus, arrows, and search where applicable. |
| 2.4.6 Headings and Labels (Level AA) | Headings and labels must describe topic or purpose clearly. | Supports | Headings and labels clearly describe content structure and purpose. |
| 2.4.7 Focus Visible (Level AA) | It must be visually clear which element is focused when navigating by keyboard. | Partially Supports | 1. Focus rings may be inconsistent, difficult to see, or non-existent (invisible for some High Contrast themes). |
| 2.4.11 Focus Not Obscured (Minimum) (Level AA 2.2 only) | Focused elements must be at least partially visible on screen. | Supports | Focused elements remain at least partially visible and are not visually obscured. |
| 2.5.7 Dragging Movements (Level AA 2.2 only) | Dragging must have a simpler alternative (e.g., buttons). | Supports | All functionality requiring dragging includes simple alternatives such as taps or clicks. |
| 2.5.8 Target Size (Minimum) (Level AA 2.2 only) | Clickable areas must be large enough (at least 24×24 CSS pixels). | Supports | All pointer targets meet or exceed the 24×24 pixel minimum size. |
| 3.1.2 Language of Parts (Level AA) | If a part of content is in a different language, it must be marked with lang. | Partially Supports | 1. Our widgets support full translation and localization. However, if a translation has not been provided or is still pending AI translation, fallback English text may appear within non-English contexts (e.g., German pages). These fallback strings are not programmatically marked with a lang attribute, which can affect screen reader pronunciation accuracy. |
| 3.2.3 Consistent Navigation (Level AA) | Navigation patterns must be consistent across pages. | Supports | Navigation elements appear consistently in the same location and order across pages. |
| 3.2.4 Consistent Identification (Level AA) | Components with the same function should be identified the same way every time. | Supports | Components performing the same function are identified consistently throughout the interface. |
| 3.3.3 Error Suggestion (Level AA) | When errors occur, suggest how to fix them. | Supports | Where input errors occur, suggestions are provided to help users correct them. |
| 3.3.4 Error Prevention (Legal, Financial, Data) (Level AA) | Users must be able to review, confirm, and correct critical inputs before finalizing. | Partially Supports | 1. Upload form has clear steps when submitting information but user does not receive a final review of a submission. |
| 3.3.8 Accessible Authentication (Minimum) (Level AA 2.2 only) | Logging in shouldn’t require solving puzzles unless an alternative is provided. | Supports | Authentication does not rely solely on cognitive tasks; alternative accessible methods are available. |
| 4.1.3 Status Messages (Level A 2.1 and 2.2) | Messages that appear (like “item added to cart”) must be announced by screen readers without stealing focus. | Supports | Status messages are announced to assistive technologies without disrupting user focus. |