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

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!

v3.7.7 has these two fixes in, plus a change to leverage :focus-visible instead of the old custom solution I’d put in. https://github.com/sampotts/plyr/releases/tag/v3.7.7

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

Hi @sampotts

Great job done on the plugin guys!

I’ve tested the beta version here and I found some issues considering the report:

3) Sliders

• I noted that the volume slider aria-valuetext could receive values like 55.00000000001%, so this get’s announced on screen readers which is a really big number. Better to make sure this is always rounded numbers, don’t need to use decimal points.

4) Menu Definitions

• The settings container still has a wrongly added aria-labelled-by attribute, which is misspelled by the way. Should be removed.

5) Settings Keyboard Access

• Settings menu open with space as expected, but ENTER is not working correctly, only opens for a second and then closes automatically.

• When inside a settings submenu, for example Captions, space works correctly (select the item and go back to previous menu with the new selection focused), but ENTER doesn’t, it goes back but no item has focus indicator.

• In iE 11, the settings menu cannot be navigated with UP/DOWN arrows as other browsers, only TAB.

• When NVDA is runing, the settings menu will not work at all, neither with Space or Enter key, regardless the browser. NVDA is free so you can install to test. To disable / enable speech mode use the modification key (in my case I set to capslock) + S.

Extra: Also noted there’s a debugging console enabled, is this intended / to be configurable?

I’ll still do some more testing here but that’s what I got so far.

Hey @fleps, I’ve just raised a PR for @friday to take a look at. Once that’s in develop then I’ll push it to a beta test page so you can take a look. I’ll also push a beta tagged version to npm.

This is great feedback and as they look like small fixes, it shouldn’t take me long. I want to make sure it’s as accessible as possible so I’ll jump onto these straightaway.

Hi @sampotts, great!

role="timer" looks like the perfect solution here, this was also proposed by an accessibility audit we received for the project we’re using Plyr in 👍

Hi @sampotts

I believe the article is more concerned about the overusing of the aria menus when not necessary, like a simple website menu that can be entirely solved with simple html semantics using ul > li > ul.

The player settings menu is pretty complex and I imagine that for this solution they believed that the aria menu was the way to go, as the consultant team take in consideration the structure that was already on the player and also to the specific user case they are testing for.

Thanks for that. I’ll try and clear those up tonight if I get time. It’s my top priority to get this wrapped up.

I have pushed the improvements to hopefully rectify the issues outlined in v3.4.0-beta.1 which is now on npm and also live here: https://plyr.io/beta. If you want to take a look and let me know. I’ll also double check myself tomorrow.

Thanks for that - I’ll revisit. From memory we’re using box-shadow - I think it just needs to be less subtle. Sorry, it’s the designer in me.

Apologies for the delay on it. I want to get it out ASAP myself too but want to make sure it’s spot on before asking you to check it again.

Hey @sampotts

About the focus on iE11, I didn’t take a look on the code but maybe check what CSS properties you are using to write the outline. I know that iE doesn’t support outline-offset for example so in some elements we had to add a 1 or 2px transparent border so the outline is correctly visible.

Or if the element already use borders with colors, then we add a 2px padding on the element parent/container, so the outline has enough space and doesn’t get cut by the parent element.

Hope that helps.

Edit: sorry about the close/open, misclicked the button -_-

Hey @sampotts, how it’s going with these fixes? I saw there’s some commits so I imagine some are already fixed?

Is there any particular issue that is harder and I may help?

This is epic. Awesome feedback and I will action it ASAP and keep you updated 😃

On 18 May 2018, at 1:34 am, Felipe Spengler notifications@github.com wrote:

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.

1. 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.

1. 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.

1. 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

elements and add role=“presentation” on the
• elements for the lists in the expanded menus. Use role=“menuitem” on the buttons in the expanded menus. Userole=“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.
  1. 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.

  1. 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.

  1. 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.

  1. 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!

  — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

Hi @sampotts , great to know that you are giving accessibility this importance.

In the meantime I will also ask to the Accessibility Consultant to do a second pass on the player to see if there’s any other issue they didn’t get, and update here if anything new is found.

Thanks!