Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Who is responsible for the user interface for PiP? #179

Open
Tracked by #219
becka11y opened this issue Apr 8, 2020 · 6 comments
Open
Tracked by #219

Who is responsible for the user interface for PiP? #179

becka11y opened this issue Apr 8, 2020 · 6 comments
Labels
a11y-needs-resolution Issue the Accessibility Group has raised and looks for a response on.

Comments

@becka11y
Copy link

becka11y commented Apr 8, 2020

As a representative of the Accessibility Platform Architectures (APA) working group I reviewed this specification for accessibility concerns. One accessibility use case we see is the display of sign language translation within the picture in picture window.

I am trying to understand who is responsible for generating the user interface to find and switch between picture in picture windows? Is the browser responsible - similar to the controls provided for the video element? Or, is the web developer responsible for including the user interface? Either way, it is imperative that this interface meets the requirements of WCAG 2.1. We are asking that you add an accessibility statement to the specification that outlines the requirements for meeting WCAG 2.1 and especially of the mechanisms for a user to find, enable/disable, and navigate to/from the picture in picture.

@michael-n-cooper michael-n-cooper added the a11y-needs-resolution Issue the Accessibility Group has raised and looks for a response on. label Apr 8, 2020
@beaufortfrancois
Copy link
Collaborator

Thanks for raising this issue @becka11y!
I'd be happy to address those in the spec. Do you have examples of other web APIs specifications that demonstrate how to meet the requirements of WCAG 2.1? Would you be able us reaching that goal?

FYI @mounirlamouri

@becka11y
Copy link
Author

becka11y commented Aug 9, 2021

Apologies for the delay in responding. We don't have any specific examples from other Web API specifications but the APA working group agreed upon the following suggestion for an accessibility statement within the specification:

It is important that the interface for picture in picture meets the requirements of the Web Content Accessibility Guidelines (WCAG). All users must be able to find and navigate to/from the picture in picture and enable/disable/operate all controls using various input modalities, color and contrast settings, and assistive technologies.

For example, the WCAG Guideline 2.1 requires, "Make all functionality available from a keyboard". Any picture in picture implementation and interface must be full operational with the keyboard only.

@tomByrer
Copy link

must be full operational with the keyboard only

So will the keyboard-focus automatically bounce to the first 'tab focus' inside the PiP when it appears? @becka11y, it not seem you answered the original topic if the browser be responsible for that auto-focus, or the webmaster is to program somethin in JavaScript.?

@Rasubra8
Copy link

I also have A similar query. If caption is not displayed in PIP mode is that A vialation of WCAGSC 1.2.2?

@marcoscaceres
Copy link
Member

So, it appears it's the browser that is responsible, but it would be good to say that the UI needs to meet the WCAG guidelines.

@chrisn
Copy link
Member

chrisn commented Mar 21, 2024

@Rasubra8 Caption display in PiP windows is a recognised issue, where some browsers support rendering of captions in the PiP window, and others do not, and in some cases captions are rendered by the web application. But, yes, the PiP window should render captions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
a11y-needs-resolution Issue the Accessibility Group has raised and looks for a response on.
Projects
None yet
Development

No branches or pull requests

7 participants