#957: Add Skip-Ad media session action
Discussions
2024-08-12
Matthew: looked at the proposed API - the way that you show or hide the button is by adding or removing an event handler for it... Fine... Assume that's consistent with other stuff... judging as it's part of media session... It looks like from this that the appearance of the button is UA controlled. So that removes one avenue for a11y issues .. if the user agent is rendering the button then the responsibility for a11y is on the user agent. The one thing I didn't yet determine is how to get to a PiP window with the keyboard... If you can't then that's a bigger problem... it does need to be keyboard accessible. Will try it out. Peter raised the point : should it be on the platform because it admits advertising as a business model for the platform... there isn't a position from mozilla. I'm reading a bit of pushback from webkit...
Dan: can you leave some feedback on the issue? We could also ask if this could be generalised .. Considering we generally don't have ad-specific APIs then maybe we could ask them to generalize this?
Dan: leaves comment
2024-09-02
Martin: we talked about this this morning... parallels to chapter metadata... could be more generic feature to skip something when the concept of chapters is added. This may fit with Peter's earlier feedback.
Tristan: Like the idea of being generic and useful for multiple purposes.
Martin: could have a skippable attr with a cause, which could provide the string for the button. This oculd improve consistency with UA controls.
Matthew: from an accessibility perspective my biggest concern is how people reach the buttons and how they are rendered. I realized that this is a much deeper issue. I'll check the review of the spec as a whole and the TAG doesn't appear to have reviewed the whole thing (MediaSession, that is). (Wrong history?) This is pretty old, but it has only ever been a working draft. We should have seen it in APA, but we don't seem to have. Correction: APA did look at it a long time ago and it probably needs another look.
<blockquote>Firstly, we need to ask whether this was implemented in browsers other than Chrome. If it wasn't, this presents an opportunity to improve it.
One desire we have is to make this feature generic, rather than being specific to skipping ads.
We observe that the Media Chapter information (that we recently reviewed) might provide a useful hook for this sort of control. "Chapters" that are skippable can be marked as such in that metadata. The type of thing to skip might be included in that information. Consider { ..., skippable: "ad" }. That would allow for skipping of intro sequences and credits in addition to ads.
For accessibility purposes, this sort of thing might need to be given a symbol so that non-textual users are able to more readily access the function. Please consult an accessibility expert about this (@matatk indicated that APA is likely to want to take another look; it's been a while since they reviewed the original MediaSession proposal).
</blockquote>2024-09-09
suggest we close this : see convo in breakout B
Martin to file the relevant issue and close this.
2024-09-09
Jeffrey: this has been supported by all 3 browsers... sounded like reasonable support ... generalizing media chapter might be a way to go in the future...
Dan: let's close it...
Jeffrey: I think we need to file the issue on some relevant repo [Yves: https://github.com/w3c/mediasession/issues/] so it doesn't get lost...
Dan: adds it to D agenda and marks as proposed-close.
Martin opened https://github.com/w3c/mediasession/issues/340
2024-09-16
general agreement to close satisfied with concerns
<blockquote>Thanks for the review request. As this is shipping in multiple engines, and our concerns have been raised in an issue to be addressed in future, we'll close this review.
</blockquote>2024-09-16
Matthew: there was a reply - there are other implementers than Chrome (Gecko). and BBC have chimed in to say a more generic one would be good. Do we close this?
Yves: do we block closing on the resolution of the issue, or say they've seen our feedback?
Matthew: plenary?
Yves: we expressed concerns - raised as an issue - so closing satisfied with concerns would be good for me. The question is do we want to block on the resolution of that issue. Should ask Martin as well.
Matthew: I agree satisfied with concerns
discuss at plenary
OpenedMay 15, 2024
こんにちは TAG-さん!
I'm requesting a TAG review of Adding Skip-Ad media session action.
This feature was initially proposed and implemented four years ago but remained disabled due to a lack of practical use cases. It already received LGTM from the Blink dev group back in February 2019. Given our team's plan to implement a feature related to this action, we are now proposing to enable it.
Explainer¹ (minimally containing user needs and example code): https://developer.chrome.com/blog/media-updates-in-chrome-73#skipad
Specification URL: https://www.w3.org/TR/mediasession/#dom-mediasessionaction-skipad
Tests: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/mediasession/setactionhandler.html
User research: [url to public summary/results of research]
Security and Privacy self-review²: This new action does not provide any new data to the website. We just add a new media session action for the website to register an action handler for, but does not expose new data to the website. See more in the security and Privacy section in the Chrome Status
GitHub repo: N/A
Primary contacts (and their relationship to the specification): Jiaming Cheng (@jiajiabingcheng), Google
Organization(s)/project(s) driving the specification: Google, SkipAd
Key pieces of existing multi-stakeholder (e.g. developers, implementers, civil society) support, review or discussion of this specification:
External status/issue trackers for this specification (publicly visible, e.g. Chrome Status): https://chromestatus.com/feature/4749278882824192?gate=6100738773614592
Further details:
You should also know that...
[please tell us anything you think is relevant to this review]
CAREFULLY READ AND DELETE CONTENT BELOW THIS LINE BEFORE SUBMITTING
Please preview the issue and check that the links work before submitting.
In particular, if anything links to a URL which requires authentication (e.g. Google document), please make sure anyone with the link can access the document. We would prefer fully public documents though, since we work in the open.
¹ We require an explainer to give the relevant context for the spec review, even if the spec has some background information. For background, see our explanation of how to write a good explainer. We recommend the explainer to be in Markdown.
² A Security and Privacy questionnaire helps us understand potential security and privacy issues and mitigations for your design, and can save us asking redundant questions. See https://www.w3.org/TR/security-privacy-questionnaire/.
³ For your own organization, you can simply state the organization's position instead of linking to it. Chromium doesn't have a standards-positions repository and prefers to use comments from the teams that maintain the relevant area of their codebase.