[Accessibility] Multiple Issues making player invalid for WCAG 2.0 AA compliance

Updated and more detailed issues reported on https://github.com/sampotts/plyr/issues/905#issuecomment-389909727

---

Original comment:

I’m working on a project that is being converted to meet WCAG 2.0 AA level compliance with the help of a specialized company to do an extensive QA on the project and report all issues found. The team found some issue on the Plyr plugin to a point that we will probably need to ditch it and develop our custom player on top of the HTML5 video tag (unless I use the non-minified version and try to fix myself)

I don’t expect this issues be fixed soon but I’m reporting them here in order to help, because many accessibility requirements are really hard to understand and we as developer tend to miss-understand some details, so this experience of having a consultant specialist working with us is being really important to learn a few things.

Here are the issues found (PS: I don’t know the exact version of the plugin, the min JS doesn’t have the version, but for sure is before v3.)

Slider

Semantic information about the timeline and volume slider control is communicated visually but the current value or the min/max value is not available to all screen reader users.

Modification Recommended

• The input type="range" and <progress> elements are not fully supported by assistive technology. Use the role="slider".
• As appropriate, use WAI-ARIA states and properties to communicate additional semantic information.
  • Provide a slider label using aria-labelledby or aria-label. If aria-labelledby references two or more element ids, set tabindex="-1" on the elements being referenced.
  • Define the current value using aria-valuenow
  • Set the min/max values using aria-valuemax and aria-valuemin

Keyboard Access and Visibility

1 - The video Play, Mute/unmute and full screen button SVG elements are keyboard accessible by default when using Internet Explorer. This may confuse keyboard and screen reader users, as there are two-tab stops for each button.

Modification Recommended

• Set focusable="false" on the <svg> element.

2 - The volume slider has no visible focus indicator. Mouse users get visible cues that a page element is actionable (mouse pointer change, rollover color change, etc.) that are not available to keyboard-only users.

Modification Recommended

• Make sure that there is a clear visual indicator when an object receives focus and when the mouse pointer moves over the object. For example, you could add an outline or change of background color.

Findable Added Content

The Video’s percent loaded (buffering) function is wrapped in <progress> HTML5 tag which, in some browser/screen reader combinations behaves like an ARIA live region. This interrupts screen reader users as they are trying to listen to the content play. There are no means to turn off this feature, so it would continue to interrupt until the video was completely loaded and since the user is not actively doing anything (because they’re listening to the video) the entire video might be constantly interrupted by the load progress updates.

Modification Recommended

• Provide a method (button) to enable screen reader users to turn this feature off. The button can be hidden visually and should be defined as an ARIA toggle button using the aria-pressed attribute. The button name should be something along the lines of “Buffer Progress”.

Hope it helps

[fleps]

Hi @sampotts

As mentioned our consultant team did an extensive testing on the player and here are the issues found and the recommendations.

1) Frames

The imasdk.googleapis.com iframe is used as a shim, or to capture events, or for data transport, but it is not ignored by screen readers. Screen reader users may be confused by information that should be hidden.

Recommended Modification Hide the iframe as follows: Use CSS display:none or visibility:hidden on the iframe element. — OR — Add role="presentation" and tabindex="-1" to the iframe element. Use the attribute title="empty" to indicate the iframe contains no user information.

2) Buttons definitions

The Play/Pause, Mute/Unmute, Disable/Enable Captions, and Enter/Exit Full Screen buttons are defined as toggle buttons but they do not indicate the state correctly because the name of the buttons changes when activated. Screen reader users will not understand the current state of the controls.

Recommended Modification

The aria-pressed attribute should not be used on buttons where the button name changes to indicate the state. This causes incorrect information to be communicated to screen reader users. For example, the Play button is announced as “Play toggle button not pressed” which is correct, but when the button is activated it is announced as “Pause toggle button pressed” which communicates that the video is paused, but it is not.

• Either remove the aria-pressed attributes from the buttons OR keep aria-pressed and do not change the name of the button to reflect its current state.
• Also remove role="tooltip" from the <span> elements used for the button names, this role is not appropriate for this content.

Note: The full screen button is not displayed in IE.

3) Sliders

The Seek and Volume sliders are semantically defined but use multiple methods to label the control. There is a label element with a for attribute and aria-labelledby referencing the label element. This may complicate screen reader interaction with these controls. In addition, the slider values are not properly communicated to screen readers.

Recommended Modification

• Remove the for attribute from the label elements and keep aria-labelledby attribute.
• The seek slider value should be communicated as the time shown visually. Currently aria-valuemax="100" and the current time (aria-valuenow) is a percentage and not the actual time.
  • Set aria-valuemax="183" (total minutes) and use aria-valuetext to communicate the actual time (e.g. aria-valuetext="00:23 of 03:03").
  • The aria-valuetext attribute should be used when alphanumeric values should be indicated to screen reader users
• The volume slider current value is not communicated properly. When the volume is at 100 the value is communicated as 1.
  • Use aria-valuetext to communicate the volume percent (e.g. aria-valuetext="100%").

Note: In IE, the PageUp and PageDown keys do not work on the sliders as they do in Firefox and Chrome. While this interaction is optional, it allows keyboard users the ability to move the slide in larger increments which increases the usability.

4) Menus Definition

The Settings menu uses dropdown menus that do not define the proper role or state information for the expanded menus. The expanded menus are instead defined as a tab control with incorrect roles and properties defined on the tablist child elements. Screen reader users will not understand this menu and will have difficulty interacting with it.

Recommended Modification

• Remove role="tooltip" from the <span> with the button name for the Settings button.
• Remove all of the tablist, tabpanel, and tab roles.
• Remove all instances of aria-labelled-by (the attribute is also misspelled, but this is not required on these elements).
• Define the menu using WAI-ARIA:
  • Use role="menu" on the <ul> elements and add role="presentation" on the <li> elements for the lists in the expanded menus.
  • Use role="menuitem" on the buttons in the expanded menus.
  • Use role="menuitemradio" and the aria-checked attribute for the submenus with radio buttons (remove the radio input and label elements).
  • In the submenus, the buttons at the top (Captions, Quality, Speed) are defined as menu buttons but they do not open a menu, they navigate back to the previous menu. Remove aria-haspopup and aria-expanded from the buttons and add visually-hidden text “go back to previous menu” so screen readers understand the action of these elements.

See http://www.w3.org/TR/wai-aria-practices/#menubutton for more information and examples.

5) Settings Keyboard Access

The expanded Settings menus do not have the keyboard interaction users expect. Screen reader users are told to use the arrow keys to navigate the menus but this does not work properly. In addition, when navigating the radio submenu items, a selection is automatically made and the menu is collapsed. Keyboard and screen reader users will have difficulty with the menus.

Recommended Modification

• When keyboard focus is on the Settings menu button, pressing space or enter opens or closes the menu.
• When the menu is opened, keyboard focus should be moved to the first element in the expanded menu.
• From within the expanded menus:
  • Space/Enter opens a submenu if present and keyboard focus should be moved to the first item or activates the menu item and closes the menu.
  • Up-arrow should move keyboard focus to the previous menu item or wraps to the last.
  • Down-arrow should move keyboard focus to the next menu item or wraps to the first.
  • Left-arrow should move keyboard focus back to the previous menu.
  • Right-arrow should open the submenu and keyboard focus should be moved to the first item, if no submenu moves to the next menu item.

See http://www.w3.org/TR/wai-aria-practices-1.1/#menu for details.

6) Buttons Keyboard Access

The buttons elements cannot be used with the keyboard consistently across different browsers and Assistive Technology/browser combinations. Content is not accessible to screen reader or keyboard users when mouse actions are required.

Recommended Modification

• Do not auto-hide the control bar when a control is activated. Before triggering the auto-hide, wait for a period of inactivity.
• Keyboard only:
  • In FF, The Play/Pause button cannot be activated with the keyboard, it changes briefly but then switches back to the previous state. For the other buttons, the button with focus activates that button but also activates the Play/Pause button and hides the control bar.
  • In IE, once the video starts, the Play/Pause button cannot be activated with the keyboard or mouse.
  • In Chrome, the spacebar only activates the Play/Pause button regardless of which button has focus.
• With a screen reader running:
  • The buttons cannot be activated using NVDA/Firefox.
  • The Play/Pause button cannot be activated using JAWS/IE.

7 ) Focus visibility

a) (IE Only) The video controls, including the menus, have no visible focus indicators in IE. Mouse users get visible cues that a page element is actionable (mouse pointer change, rollover color change, etc.) that are not available to keyboard-only users.

Recommended Modification Make sure that there is a clear visual indicator when an object receives focus and when the mouse pointer moves over the object. For example, you could add an outline or change of background color.

b) Keyboard focus indicators are used in Firefox and Chrome but are difficult to distinguish against the colors used for the buttons and background for the large Play button overlaid on the video and for the seek and volume sliders. Keyboard-only users and low-vision users may not be able to see where they are on the page.

Recommended Modification Change the focus indicator to be more visible. If a custom focus indicator is used, it should have at least a 3:1 color contrast ratio between the color used for the focus indicator and the background it is used on.

8) Tab Order

The non-interactive video container is in the tab order. Screen reader and keyboard-only users expect only interactive elements to be in the tab order. In some browsers/screen readers, this will be announced as “clickable” which will be confusing to screen reader users.

Recommended Modification

• Remove the tabindex="0" from all non-interactive elements.
• In addition, remove the aria-label attribute, its use is not valid in this context: <div class="plyr plyr--full-ui plyr--video plyr--html5 plyr--captions-enabled plyr--fullscreen-enabled plyr--captions-active plyr--paused">

9) Contrast on focus

Image icons used for the video controls have insufficient contrast (less than 3:1) when they have keyboard focus. Users who are color blind or cannot perceive color may not perceive the content.

Recommended Modification Increase color contrast to have 3:1 color contrast ratio when the buttons have focus.

Note: This issue is has low priority because it is not currently a requirement under WCAG 2.0 however, it will be a requirement in the upcoming WCAG 2.1.

10) Valid Markup

The video player contains coding errors that may prevent assistive technologies (AT) from interpreting content correctly. AT users may be unable to perceive or interact with page content and forms.

Recommended Modification Fix the validation errors.

---

That’s it Sam.

As I mentioned, this became more complex than I was expecting, so let me know what are you thoughts on this, and also if you need clarifications on any of the issues reported.

If you decide to fix this, when everything is completed I’ll ask the consultant to verify the player again and see if everything is ok.

Hope it helps!

[sampotts]

OK I’ve fixed the majority of these issues in this commit: https://github.com/sampotts/plyr/commit/a97b08e8ea0022646eae005ce64a7edf8b26fb29#diff-502df26753b20c330d95456a4c8db867

Some notes:

• A screen reader only <label> was already being generated for the <input type="range"> but I guess the aria-labelledby attribute re-enforces that link between label and input?
• The <input type="range"> do have keyboard focus styles but probably need to be less subtle. I will work on improving those
• I’ve not added the button yet to toggle the <progress> element updates but will do that next