Level A (Yes)
Level AA (Yes)
Level AAA (Yes)

Level A (Yes)
Level AA (Yes)
Level AAA (Yes)

Level A (No)
Level AA (No)
Level AAA (No)

Icon buttons have title or aria-label attributes on the button element. SVGs inside the buttons have attributes to hide them from screen readers.

Documented workaround: Partners need to include a text transcript on their page, or link to their transcript near the player.

Partners need to upload captions in DM Studio. We also auto-generate captions using Artificial Intelligence

1.2.3 Audio Description or Media Alternative (Prerecorded) (Level A)

Documented workaround:
Partners need to include a transcript on their page, or a link to a transcript. OR Upload a second version of the video with audio-description, and place a link near the player to this alternative version.

Semantic html is used throughout the player (e.g. <a> for links, <button> for buttons, <input type="range"> for sliders).

The most important control is most visually prominent and first in the source order: the play/pause button. The rest of the source order follows visual presentation (play button, then top to bottom left to right).

No instructions in the player.

The player is monochrome and doesn't rely on colour anywhere

The player has buttons to pause the video and mute the sound

The whole player can be fully controlled using only keyboard interactions.

Users can move keyboard focus freely inside/outside of the player. If they open a modal or menu in the player, keyboard focus cycles inside it until they dismiss the popup (via keyboard or pointer).

The player keyboard shortcuts only work when focus is inside the player iframe.

The "Up next" screen has a timer that can be cancelled by the user: via the X button or by scrolling the carousel.

If the player starts automatically, the user can pause the video with the player controls. If the seek bar is considered moving/auto-updating information, that can be hidden by the user by hiding controls via pointer or keyboard.

Flashing elements in the player, such as the next video indicator during the countdown, are below the threshold (slow 2 seconds per flash). Partners need to ensure their videos don't contain flashing content that can cause seizures.

The player is an embeddable application, not a set of web pages.

The player embed has a title element containing "Dailymotion Video Player" and the title of the video or playlist.

The most important control is the most visually prominent and first in the source order: the play/pause button. The rest of the source order follows visual presentation (play button, then top to bottom left to right).

Links in the player contain meaningful text (eg. title of the video, or "Privacy Policy"). Image links have meaningful alternative text (eg. "Embed (opens in a new window)").

All features can be activated with simple taps/clicks/keypresses (e.g. seek, change volume, enter full screen, etc.). Gestures are not required.

Buttons in the player only activate when the click/tap event is complete (i.e. on the up-event)

Wherever interactive elements display text (e.g. in menu), the accessible name of the element matches or contains the on-screen text.

No device motion used in the player

The html element in the player iframe contains a `lang` attribute that (along with the entire UI) is determined by the user's browser preferences.

Actions only happen when the user activates a control (e.g. Return keypress or click), not on focus.

Changing the setting of a menu item (e.g. choosing an option in the subtitles submenu) causes a change of content (back to the main menu) – but not a change of context (close the menu completely). Keyboard focus is returned to the menu item and doesn't leave the menu.

Evaluated against WCAG version 2.1, so 2.2 criteria does not apply.

When a user enters an incorrect password for a password-protected video, an error message is displayed under the form field.

The password screen shown for password-protected videos has a clear title (Private video), a placeholder in the form field (Password...), and instructions below the form field (You need a password to watch this video).

Evaluated against WCAG version 2.1, so 2.2 criteria does not apply.

4.1.1 Parsing (Level A)

• WCAG 2.0 and 2.1 - Always answer "Supports"
• WCAG 2.2 (obsolete and removed) - Does not apply

For WCAG 2.0 and 2.1, the September 2023 errata update indicates this criterion is always supported. See the WCAG 2.0 Editorial Errata and the WCAG 2.1 Editorial Errata.

The player is coded to be compatible with the accessibility API:

• HTML titles or ARIA labels for component names (when there is no visible text)
• semantic HTML or ARIA roles for component roles
• various other attributes for the state, value and other properties

Documented workaround: Partners need to use an external live captioning provider and include a link to the live captions near the player.

Documented workaround: Partners need to upload a second version of the video with audio-description, and include a link near the player to the alternative version.

The entire player UI adapts to any orientation and screen size

The player uses <input type="password"> for the password screen, unless the user wants to see what they've written: then it changes to <input type="text">

Note: “Partially supports” conformance level chosen due to difficulty calculating contrast precisely: colours in the video itself directly impact contrast ratios.

Text in the player is white.

Menus and popups have a dark background colour that achieves the required contrast ratio.

Controls also show with a gradient background using the same dark colour at the top and bottom, to try and achieve the required contrast ratio.

The player uses relative sizing everywhere, so that both icons and text scale according to user preferences.

The player uses real HTML text everywhere. Partners should avoid putting text in their video posters.

The player is responsive and stays usable at smaller sizes until a width of about 220 CSS pixels.

Note: “Partially supports” conformance level chosen due to difficulty calculating contrast precisely: colours in the video itself directly impact contrast ratios.

Icons in the player are white.

Menus and popups have a dark background colour that achieves the required contrast ratio.

Controls also show with a gradient background using the same dark colour at the top and bottom.

1.4.12 Text Spacing (Level AA 2.1 and 2.2)

Text in the player responds to user style overrides. When text gets too long it truncates with an ellipsis.

1.4.13 Content on Hover or Focus (Level AA 2.1 and 2.2)

The volume slider shows on hover/focus of the mute button. The volume slider only hides when the user removes hover/focus from the mute button and/or the volume slider.

2.4.5 Multiple Ways (Level AA)

The player is an embeddable application, not a set of web pages.

2.4.6 Headings and Labels (Level AA)

Headings in the player are descriptive (e.g. "Share", "Settings", etc.).

2.4.7 Focus Visible (Level AA)

Keyboard focus is shown with a thick dotted outline in the player.

2.4.11 Focus Not Obscured (Minimum) (Level AA 2.2 only)

Evaluated against WCAG version 2.1, so 2.2 criteria does not apply.

2.5.7 Dragging Movements (Level AA 2.2 only)

Evaluated against WCAG version 2.1, so 2.2 criteria does not apply.

2.5.8 Target Size (Minimum) (Level AA 2.2 only)

Evaluated against WCAG version 2.1, so 2.2 criteria does not apply.

3.1.2 Language of Parts (Level AA)

Video titles displayed inside the player have a lang attribute that matches the detected language of the title.

3.2.3 Consistent Navigation (Level AA)

The player is an embeddable application, not a set of web pages

3.2.4 Consistent Identification (Level AA)

The player is an embeddable application, not a set of web pages. But components with the same functionality are identified consistently across different screens.

3.3.3 Error Suggestion (Level AA)

The password screen shows an error message but can't provide suggestions due to the nature of the content (password required). This falls under the allowed exceptions.

3.3.4 Error Prevention (Legal, Financial, Data) (Level AA)

The player doesn't collect legal or financial data.

3.3.8 Accessible Authentication (Minimum) (Level AA 2.2 only)

Evaluated against WCAG version 2.1, so 2.2 criteria does not apply.

4.1.3 Status Messages (Level AA 2.1 and 2.2)

The player uses aria-live attributes to notify assistive tech users of status messages (e.g. "Link copied" message in share screen, menu title changes, end screen countdown, ad skip button available).

Documented workaround:
Partners need to upload an alternative version of the video with embedded sign language interpretation. They can provide a link near the player to this alternative version.

1.2.7 Extended Audio Description (Prerecorded) (Level AAA)

Documented workaround:
Partners need to upload a second/third version of the video with extended audio-description. They can provide a link near the player to this alternative version.

Documented workaround:
Partners need both a text transcript AND audio description.

Documented workaround:
Partners need to use an external live captioning provider and include a link to the live captions near the player.

Every component uses semantic markup and has extra attributes added for assistive technologies. Text alternatives describe the purpose and not what it looks like (e.g. "Close" and not "X", "Share" and not "Paper plane").

Contrast conforms to AA level only.

The player provides a mute button.

The player has no blocks of text.

The player uses real HTML text everywhere. Partners should avoid putting text in their video posters.

The whole player can be fully controlled using only keyboard interactions.

The "Up next" screen has a timer on by default. Partners can fully disable the autonext feature in their player configuration.

The player has no alerts or interruptions.

The player doesn't require authentication.

The player doesn't keep user data.

Flashing elements in the player, such as the next video indicator during the countdown, are below the threshold (slow 2 seconds per flash). Partners need to ensure their videos don't contain flashing content that can cause seizures.

There is no way to disable transitions and animations in the player.

The player is an embeddable application, not a set of web pages. If this criteria was applicable to the player, users can see where they are in the queue of videos by opening the "More content" screen. This list is also displayed on the end screen after every video.

Links in the player contain meaningful text (eg. title of the video, or "Privacy Policy"). Image links have meaningful alternative text (eg. "Embed (opens in a new window)").

The criteria covers sections within pages of writing, not user interface components.

Evaluated against WCAG version 2.1, so 2.2 criteria does not apply.

Evaluated against WCAG version 2.1, so 2.2 criteria does not apply.

Controls are 40px or 48px depending on the size of the player

The player can be used with any combination of interaction modes (e.g. mouse + keyboard). Hybrid devices get a dedicated menu item allowing them to toggle on/off touch mode.

No jargon or unusual words are used inside the player.

No abbreviations are used inside the player.

The player doesn't contain text that needs high-school level reading.

No ambiguous words are used inside the player.

Users can turn off autoplay of subsequent videos by cancelling the timer in the "Up next", but they only have a few seconds to do so. Partners can fully disable the autoplay next feature in their player configuration.

Sharing links that open new windows are identified with title attributes that contain extra text ("opens in a new window").

Browsers often show titles in tooltips on hover.

BUT menu items that open new windows are not identified (e.g. "Manage cookies", "Privacy policy").

The player doesn’t have contextual help.

The password screen provides a button for users to show/hide the text they're typing in the form field.

Evaluated against WCAG version 2.1, so 2.2 criteria does not apply.