Meeting minutes
Introductions and Agenda bash
Nigel: Good morning, welcome everyone.
… Agenda for today
[Nigel presents the agenda, asks for AOB, checks timings]
Igarashi: attending as AB member. Adding one topic.
Igarashi: 5 minutes AOB to talk about the Process from the AB perspective
<Igarashi> https://
Andreas: subtitle formats in general, and W3C position, can we cover as part of interop testing?
Nigel: any issues with the agenda and timing? Seems no.
Nigel: please introduce yourself, name, who you work for.
[each person introduces themself by name and affiliation]
Process (AB)
Igarashi: The process taskforce can be joined by everyone.
… to improve process. We are visiting every group to get feedback.
… we don't have much time to go into detail but please approach myself or Tess.
Tess: we heard from a lot of people that aspects of the process are cumbersome, convoluted.
… we don't have a lot of detail about what that means, that is why we make the rounds.
… we are not looking for a series of grievances, if there are specific aspects that should be preserved or changed, we need to hear that too.
… that is the pitch. If you see people with purple badge, they are obligated to talk to you and listen.
Igarashi: I am available as well.
… any thoughts?
Nigel: I have already provided a lot of additional feedback. I am largely OK with how things are. One thing to keep is if people are wokring on rec-track spec,
… the goal needs to be to get to Rec. If that is not the goal, if they don't need wide review to complete, don't waste W3Cs time.
… That would give the document a false sense of authority.
Pierre: that is worth a longer discussion, there are many repo issues. Should we set time aside later for this?
Tess: if you have specific feedback, or know people on the AB, track us down. Let's not take up working group time.
Pierre: let's make a proper agenda item for it.
Nigel: it might end up being quite late.
Tess: can be back at 4:30
Nigel: maybe before afternoon break but let's not prioritize over the agenda.
… thanks for the input.
… editing the agenda to insert process feedback at 15:15.
IMSC 1.3
Nigel: status is we are in working draft.
… wanting to move to CR snapshot
… (shows the repo) working draft is from September. We have a PR open, which we should cover.
… in terms of wide review it is complete in my view. Is that right?
Nigel: we are waiting on accessibility.
Pierre: don't understand what that means.
… what more do we need to do?
Nigel: we did not say in the issue that it was early draft review. Just a WD review.
… we have not had a response back
Pierre: this is purely editorial
w3c/
Pierre: i think we are done. In terms of process, and practically
Nigel: agree
Pierre: what is the objection?
Francois: The review was understood to be a WD review only, Janina says she has no objection.
Pierre: they can revisit at any time. This is purely editorial. They can file an issue.
Francois: to close wide review, an ack from their side is all that is needed.
… just announce that the review is to be closed.
Pierre: agrees.
… comment on process: a minor improvement stalls process unduly.
… this is a truly minor issue. If this was fundamental then things would be different. This is an informative note to a small feature
… of a spec that has been around for years.
Nigel: we will say "review complete, no substantive changes". Discussion around subscript/superscript is editorial. Is that fair?
… any other things we need to discuss on 1.3? Will come to a proposal to discuss CRS, will get later to it today.
Pierre: substantive question is PR 614.
Improve the ja character set per ARIB feedback w3c/imsc#614
github: w3c/
Pierre: we added a recommended charset based on ARIB input.
… unfortunately, there is in the liaison some vagueness. We should make sure we get it right.
… we asked for more details but got no clarification.
… don't want to remove the text but we need clarification. This is informative (should not a shall), it is usefull but not necessary.
Nigel: I think that the idiographic selector is not defined where it says it is.
… translation issue?
Atsushi: this is not a stopping issue
Nigel: If your colleague [from NHK/ARIB] comes later, let's ask them
… is there a choice of terminology and we need to use the correct one?
Pierre: this is a complex part with many things falling underneath it.
… what would be most useful would be an example of what is meant.
… I find it a complex part of the Unicode spec.
… as atsushi pointed out, terms may have changed. Ideally have an example.
… here is sample text that uses IVS, and here is what we expect the rendering to be.
… and we could it include in the spec actually.
Nigel: this is unresolved right now. so we are saying we can proceed to CRS without resolving?
Atsushi: agrees.
Nigel: we merge later.
Atsushi: this is not normative, so don't need another CRS
Nigel: we can put change in and request transition to rec
… implementation report will be empty. It is a formality.
SUMMARY: Hold this PR open pending feedback and hopefully an example, and do not hold up CRS publication
forcedDisplay and visibility="hidden" #484
github: w3c/
Nigel: Note that in one of the breakouts yesterday, was pointed out there is a new API
… about selecting or signaling to assisted tech which notification to expose, to allow user filtering?
… it was news to me yesterday.
… the scenario was one where two people watch a movie, one of them needs hard of hearing subtitles, the other one is screenreader user
… and wants to choose whether captions are exposed or not.
James: please do share more about this, it is new to me
Nigel: filtering can only be done on data and tags.
James: I don't understand, this seems a side conversation.
Nigel: it is closely related actually. This is about not just hiding things but also ensuring that assistive tech does not see things that are hidden
… need to go back to Matt and find out what the new API is. Propose we defer for IMSC 1.3. Or include as editorial.
Pierre: agrees
SUMMARY: @Nigelmegitt to check about the new AT notifications API, defer to a later version of IMSC or include in IMSC 1.3 CRS if editorial
CRS Publication
Pierre: we need a resolution
PROPOSAL: Request transition of IMSC 1.3 to CRS without being dependent on open pull requests being merged
Nigel: Any thoughts, objections etc?
Gary: Ship it!
Atsushi: If we cannot conclude on w3c/imsc#614 before AC review for entering Rec,
… we may want to remove some of the new text.
Pierre: We could make the pull request cover the entire JA character set so if it does not get merged
… then it is not there.
Atsushi: Maybe having nothing is better than having it wrong
Nigel: I'm not sure it is wrong
Pierre: The pull request is a tweak to a previously merged PR.
… The proposal is either to include a JA character set or not, in its entirety, including the PR
… Instead of playing with the pull request, we can note it - unless it can be agreed to,
… the entire JA character set might be removed.
Nigel: Works for me.
RESOLUTION: Request transition of IMSC 1.3 to CRS without being dependent on open pull requests being merged
Gary: is the api aria notify? https://
James: not sure how it is relevant to TT
… ariaNotify is a first version for a better version. rules out accidental notifications.
… a web author might accidentally put role=status ...
Regulatory changes and new API proposal (Apple)
Dana: [shares slides]
<jernoble> FYI Explainer Link: https://
Dana: I'll present a new API that Webkit is proposing to meet new requirements from FCC
… Goal of the FCC regulation is to make system level caption style settings "readily accessible" to users
… Begins August 2026
<hober> The FCC document in question: https://
Dana: 4-part test: Proximity, Discoverability, Previewability, Consistency and Persistence
… Scope of API
… Proximity: asks that the settings be accessible via something like a button within the app
… or page, without forcing a switch of application or a lengthy process to access caption
… display settings.
… Web app responsible for displaying settings
… Discoverability: requires user testing of the web app to ensure discoverability
… Previewability: user to be able to see a preview of their selected style on the video
… Consistency and Persistence: user settings to persist across apps
… User agent proposal for Webkit is:
… for Previewability, UA would hide current captions, and provide an example text cue
… and style it to match the user's current profile choice
James: To clarify this is how Webkit proposes to implement a compliant solution that
… meets the new requirements
Nigel: Why hide the current caption, isn't a real caption the best example you could have?
Jer: There might not be a current caption
James: The tech stack might only be able to preview a predefined caption
Tess: The example caption would stress the different styles
Gary: Would the video pause?
Jer: If the application wants to pause, that would be up to the app
Dana: Consistency and Persistence:
… UA will read the system Media Accessibility settings
… Convert those settings to CSS styles
… Apply those styles to cues rendered by the video element
… Webkit already implements this
Nigel: What about settings that don't have CSS, like raised edges?
Eric: We can simulate raised edges in CSS
Jer: There is a style that the FCC mandates that you can set in system preferences that
… is not exposed to the web, which is the block level element that surrounds the cue
… rather than the inline. There is a PR open on WebVTT specifically to represent that block
… level element. So that all the styles will be implementable in CSS.
<jernoble> FYI, issue in question is: w3c/
James: Nigel you may remember discussing this in another place about terminology differences
… like "window" and defining those.
Dana: [shows WebIDL]
… There would be a new method on the HTMLMediaElement that would return promise
… to show the caption display settings
… Once the user has selected a style the menu will close and the promise will resolve.
Tess: If the website uses the browser's default media controls this is unnecessary.
… This is for pages that implement their own media controls, to support a button that allows
… the user to do this.
Dana: Example use cases
… [shows sample code]
… When the user clicks the button, the event handler calls the API, the
… UA places the menu where the cursor is.
… More complex case, where an anchor node and position area are provided.
… In this case WebKit would try to place the menu adjacently to the top right of the caption settings
… button. If there's no space there's a fallback algorithm.
Tess: That fallback algorithm is defined by CSS Anchor Positioning.
Dana: In this case the anchor is the settings button at the bottom right, and there's no room
… to the right so we place it to the left.
… Last example: in the click event listener, the website first hides its own caption menu,
… then calls the API, and once the promise has resolved, the website restores its caption menu.
Dana: That's the presentation.
Nigel: Let's open up for discussion.
Gary: One question: has this been brought up with other browser vendors?
… Have they shown interest?
Dana: First time bringing it up was last week at FOMS
Jer: I was there and presented this.
… This is part of the outreach we would like to do to encourage other browsers to be interested
… and to show this is a good solution.
… Chrome on Mac already has the second half of this implemented - it already reads system
… preferences and turns it into CSS that applies to the cues.
James: Sometimes FCC gives notice and time to reply, but for some reason they didn't do it here
… with captions. This is a reasonably short timeline.
Andreas: Thanks a lot for the presentation. Always good to have a standardised approach on this.
… I haven't fully understood the webkit part vs the standard part.
… As I understand it you have a proposed API to display this.
… Everything else in terms of presentation is browser implemented?
Dana nods
Andreas: Some web apps might implement with WebVTT, others with other mechanisms like IMSC rendering.
… They have the same requirements.
… So every app would need to have this access to media settings.
Jer: None of us here is a lawyer!
… We can't advise which apps are covered and what the requirements are.
… We can though provide a solution in the case that a web app decides that they are covered.
… Above and beyond, to give users access to the system style settings.
<jcraig> Repeat from above: The FCC document in question: https://
Jer: If you are a writer of a web app and you don't believe you are covered,
… then this probably isn't relevant to
… you unless you want to use it.
Gary: It seems like, indirectly, if you fall under the jurisdiction you need to do native rendering
… of captions on the platform.
Jer: I think we can get to solutions for IMSC clients, either later today or another time.
… Short of allowing IMSC to be a full web format.
Pierre: Why not?
Jer: Because it's not the minimum we can do
Pierre: It would be a solution
Nigel: There's a huge number of questions in my mind about this!
… Things like what if the site wants to provide the preview caption?
… What if the site doesn't use native rendering because it doesn't work properly?
… What if the user wants their settings to be associated with their profile not their device?
<jcraig> Jer mentioned "multichannel video programming distributors" MVPDs as defined in the R&O
Nigel: What if the actual presentation is some combination of authoring and adjustments,
… the UA doesn't know what's authored
… Lots more questions!
James: You can go from the new menu into the system level settings
Jer: You can choose whether to override the authored styles or not
Nigel: Doesn't cover the middle ground of wanting to manipulate the authored content
… rather than overriding it, e.g. adjusting the colour palette
Pierre: Today you have applications that offer caption customisation directly from their player skin.
… What does this change for them?
Jer: You should probably read the FCC regulation. That's what I had to do to understand
… what we're providing here.
… I don't think there's anything wrong with adding styling on top of the user styles.
… The regulations say the user must be able to access the system settings
… and this proposal allows that.
… An existing caption setting button misses the ability to read/write system settings.
… The proposal doesn't address that.
Pierre: To avoid fingerprinting apps cannot read or write system preferences.
… So the system style has to be supplied by the UA. So far UAs have not implemented timed
… text sufficiently for this to happen. That's been the blocker for the past 8 years.
Andreas: This whole effort is driven by regulation in the US.
… All the accessibility and caption settings are also the target of European regulations.
… The European Accessibility Act also suggests users need to be able to adjust settings
… like for captions.
… In general whatever is specified in standards needs to reflect global requirements
… What you have proposed is only a small part of the problem.
… How can we broaden the perspective to deal with this issue for different situations,
… to implement access from applications to the caption settings
… The question is if we can do that, and also a comment that if something is put now into
… a global standard we should make sure it does not conflict with other regulations or requirements.
James: The EAA mandates that captions be available in general but is not at this level of
… prescription for this particular new feature.
Andreas: There would be a longer discussion, but it does mandate user adjustment of
… settings and then the referring standard EN 301 549 has further settings, not in that
… detail (of the FCC) but affecting the same area, that some settings at least need to be exposed.
Eric: One of the positive things about this proposal is that its quite generic.
… It allows a web app to request that the UA displays some caption settings but it doesn't
… mandate what is in those.
… It is possible to have different kinds of settings to be available depending on the region
… that the web app is running in.
Tess: To clarify, you said that it would require exposing the settings but I think it requires
… the honouring of settings, which is a big difference.
Andreas: Can look into the details, but independent of that, if something goes into web
… standards it should not be specific to FCC requirements but should meet wider requirements.
… Extending the scope, maybe we need to do more work than that on this topic,
… defining best practice, because a lot of stakeholders are struggling with this.
Tess: What Dana presented is what we think is a reasonable approach to comply with the
… requirements in the timeframe. That's not the end of the discussion, it's the beginning,
… because we want the web to continue to be viable for much longer.
Andreas: The European requirements are in place already.
James: I'm familiar with the EAA and EN 301 549. There are other ways to comply to EAA
… without meeting EN 301 549. It's a "safe harbour" way.
… Everything related to captions and subtitles in EN 301 549 does not get to this level of
… prescriptive detail about the UI.
… I don't see this conflicting with any other worldwide standard I'm aware of, but if you know
… of something specific we should discuss it.
Gary: I would agree with the sentiment Andreas raised that web standards work should apply everywhere.
… I agree that this wouldn't be an issue with other regulations even though the FCC originates it.
… My main question was: earlier there was the topic round IMSC and how to handle custom rendering
… and I was wondering if there was more info around it or is the main direction for that
… the existing direction for captions with TextTrackCue constructor or something else?
Eric: We don't have anything beyond the TextTrackCue constructor that takes a document
… fragment with appropriate pseudo-classes so the web app can identify the different parts of
… the fragment.
Nigel: There's a lot more to discuss here but I just want to flag that it's not obvious that this
<gkatsev> the TextTrackCue explainer https://
Nigel: is in scope of the TTWG, which is chartered to look at formats not APIs.
Tess: The HTML Media Element API is defined in the HTML spec, and this is a change to that API
… so I would expect this to be proposed and iterated on in the HTML spec in WHATWG.
… But this group has the right expertise, and these are the right people to get feedback on it.
… Chair's decision about scope.
… These are the right experts to be talking to, regardless of the formalities.
Gary: The charter specifies what documents we produce,not what discussions we have.
Tess: I hope what goes in the HTML spec will be better for this discussion.
Gary: I agree
Nigel: If WHATWG actually wants my views, they are: support IMSC natively!
DAPT issues and pull requests
Nigel: Firstly, CR must have issues.
… Filtering the open issues on CR must have label, there are none open. That's good!
… I also want to look at the two pull requests, and publishing a new CRS.
Expand the security considerations section w3c/dapt#329
github: w3c/
Nigel: request was from security HR
… [reading open issue]
Nigel: opened PR and reviewer said LGTM, will merge shortly
[review changes by htmldiff]
Nigel: added entire security consideration section
Nigel: in #serialization, there are clarification on BOM
Andreas: WebVTT has nothing about BOM, should we strict here?
Nigel: when validating much TTML documents, some has BOM, implementation sometimes re-encodes BOM as text
Cyril: pointing XML entity attach description at https://
Nigel: do we need more time for review this PR?
… PR has been reviewed and approved by security colleagues
Cyril: how about with 2 weeks period
SUMMARY: Continue with usual review and merge process
Clarify requirements for Represents w3c/dapt#328
Nigel: this PR is coming from implementation experience
… there is a circular definition of Script Event:
… if a <div> does not contain other <div>s
… but does contain invalid attributes where they are required to be valid
… for the element to be considered a Script Event, then it is not a Script Event,
… so the attribute is no longer required, so the status is unclear.
… We have discussed around this several times
[Nigel describe PR overview]
Cyril: reading now, and will do review
Cyril: for "Add definition wrappers to namespace prefixes", it bothers me that it is possible to have invalid daptm:represents values.
Nigel: The valid values for content-descriptor are defined by the registry, and you can have user-defined values there
… but anything else would be an "invalid" value, we can't change that.
Cyril: will comment to the PR
SUMMARY: Review to continue
Dealing with at risk features
Nigel: There are a number of at-risk features in DAPT
… we can either remove them or remove the at-risk status.
… We can do that just before going to AC review for Rec transition without an additional CRS.
Nigel: If we remove an at-risk feature do we need another CRS?
Francois: If you remove an at risk feature you can move ahead - that's the purpose of them
Atsushi: Maybe, but if you get a comment about removing an at-risk feature, for example
… horizontal review says an at-risk feature is required, you may need to ask for a review.
Gary: The process explicitly allows removal of at-risk features for substantive changes
… when moving to the next stage of the process without doing a new CRS.
<gkatsev> revising a CR section of the process document https://
Nigel: Just for clarity, none of the horizontal reviews have commented about any of the at-risk features.
… Not sure what our best option is,
… could just remove the at risk flags,
… or review on a case by case basis,
… or wait for more implementation experiences.
… Maybe I will follow up with implementers who currently take specific approaches that
… would affect the at risk features.
Progress to next CRS
Nigel: My proposal is to complete the review and merge process on the open pull requests
… and then request a new CRS.
Cyril: What's stopping us from moving to Rec?
Nigel: We need a new CRS first.
… I think we have completed HR.
Atsushi: Security has a comment that we have a PR to address.
… i18n has a comment on language.
… Only i18n and security remains.
Nigel: we've got comment from i18n on daptm:langSrc at closed issue
Nigel: This requires a reversion of a pull request we merged, based on seemingly changing advice
… from i18n, though maybe that's our misunderstanding.
… The reversion should:
… * allow an empty daptm:langSrc
… * make the default value the empty string
… * Not suggest using the und value
… I can prepare a PR to do that.
… Then the next thing is to complete the implementation report
Cyril: I think we can do that, we have 2 implementations.
Nigel: BBC implementation passes all of existing tests, and will be turned into open shortly
Cyril: Our implementation does not do everything now, but most things.
… The only thing it does not do is the audio description parts.
… It's an authoring implementation.
Nigel: I will follow up with the implementers who are working on audio description, and need to confirm if we can get a 2nd implementation for those.
[cyril review items implemented in their one]
Nigel: Anything else to be considered in implementation report?
[none]
Nigel: In summary, we are in the implementation phase, and need a 2nd implementation for
… every feature. A new CRS is reachable, then we can request transition to Rec when the
… Implementation Report is complete.
WebVTT interop testing
Gary: I do have some things for WebVTT but because of time we may not get around to it
… but I will raise them at our regular meetings and encourage the right people to join,.
Dana: First thing was a PR open.
<Dana> w3c/
Add support for ::cue-backdrop w3c/webvtt#528
github: w3c/
Dana: This adds the block level wrapper around inline content.
… This is required by some CEA standards.
… Webkit and Chromium already implement it but it isn't in the spec.
… Jer opened the PR to add it.
… From the discussion it seems that the name of it was contentious.
… cue-backdrop was settled on, it seems.
… Can we merge it or are there any comments or objections.
Gary: Also it is the equivalent of the "window" FCC requirement
Gary: It would be good to get the other browsers to comment on that.
Alastor: I will take a look and leave a comment
Gary: Do we know anyone at Chrome or is this something we need to chase down separately?
… Anyone specifically?
Eric: We should ask Philip. He can point us to the right person.
… He was at MEIG yesterday
Dana: OK
… I can ask Philip about it.
Gary: I don't have any blockers aside from the other vendors.
Nigel: I had proposal to change name to -background
Dana: don't know which one we should use -backdrop or -background
Nigel: TTML has concept of region as box to be placed
Gary: WebVTT region is inline block element
… similar name could be confusing?
Nigel: positioning is block level and similar?
Dana: So I need to get the answer from whoever is responsible for Chrome if they can accept this.
Gary: I can also ping Ted from FOMS/Demuxed and pursue that channel as well.
SUMMARY: Request feedback from other browser vendors on the feature and name of the element before proceeding
WebVTT should allow pages to modify the caption display area w3c/webvtt#531
github: w3c/
Dana: This issue proposed a new pseudo element that represents where the cue is allowed to
… be rendered, excluding where top or bottom controls are.
Dana: It's not possible to test the requirement for captions not to overlap controls
… but this proposal would allow it. Not sure the latest status.
Gary: This is another naming issue - I think the current proposal is cuecontainer
… The idea is to expose what's already there so we can expose styling
Dana: Q: what properties should we allow the website to style?
… Jer had suggested allowing top, left, bottom and right as well as transition so that
… changes can animate.
Nigel: Why not position and size?
Dana: I'm not certain, top, left, bottom and right would be sufficient.
… We know the position that's on top of the video.
… We just need to allow it to be shortened from either edge.
Nigel: The trend now seems to be to use position and size.
… For example, what would happen if right is smaller than left?
Gary: inline size and block size might make sense in addition to top/bottom/left/right
Nigel: There's discussion in the thread where I've mentioned this is an undercooked solution,
… that doesn't work with controls in the centre.
Gary: I think there could be a lot of work, and this gives a good baseline.
… One thing we discussed at FOMS is that you can create a custom track element with
… custom captions that are positioned to avoid controls, so that's a hack to make sure that
… your cues don't interact with custom player elements.
Pierre: Wasn't it last year that there was a proposal to basically allow a subset of HTML to be
… used as an overlay and have applications render subtitle tracks to that subset of HTML,
… so the application would have complete control rather than doing it declaratively.
… What happened to that proposal.
Eric: 3 or 4 years ago we wrote that explainer and it didn't get any feedback.
Pierre: It's a much more flexible solution than dealing with all these edge cases.
Eric: It's a good solution for people who want to render their own captions.
… This is a good solution for custom controls with native caption playback.
Pierre: If someone is using the default player that's one thing.
… But if you're doing your own thing there are lots of libraries out there.
Gary: I've built players with custom controls and native caption rendering.
… Also this would be helpful for the FCC regulations discussed earlier.
Nigel: If this is a baseline, how could you extend it later to meet the more complex requirements?
Gary: This might not be able to meet the central controls requirement.
Nigel: A good API design would allow for future extension, and I don't understand the model for this.
Gary: This might not be extensible. People do this in the wild by looking in the shadow DOM
… and inspecting the controls. It would be good to expose that.
… From the interop perspective it says controls should not overlay captions, but given that
… each vendor has different controls, it means you can't have a good test for that since
… everything will move separately.
… If you can modify the caption display area you can approximate that feature.
Nigel: There's already a comment about using the existing collision avoidance.
… The idea is to tell the player "here's where are my controls are" and it synthesises a
… "cue" to avoid collision.
Eric: It wouldn't allow the page to animate collision avoidance of captions.
Nigel: Why? Isn't that a secondary concern anyway?
Gary: Two concerns: 1. You shouldn't have captions show up where you have controls
… or vice versa. 2. In a lot of apps when controls are showing the captions are at the bottom
… but when controls appear the captions slide up.
Nigel: That's assuming a particular design?
Eric: No, it's flexible design
Nigel: Animation is an orthogonal concern - in both cases you're expressing either in the positive
… or negative some description of where you can put captions.
Gary: [scribe missed a bit] It wouldn't be able to animate
Nigel: I don't understand what the difference is
Gary: In the end maybe do both, this codifies an existing common pattern that doesn't
… work across vendor right now because Firefox doesn't use shadow dom
Dana: Maybe we can look at websites that already hack this and see what properties they use
… to guide what properties we allow.
Gary: We also discussed this in #503, where we considered passing rectangles to the video element.
<gkatsev> related discussion w3c/
Gary: Next steps are to get other vendor buy in as well
… I think top/bottom/left/right is the bare minimum.
… It would be good to look for other minimal properties that might make sense
… like inset.
SUMMARY: Look for other vendor views
Lunch
Subtitle purpose field in TV-Anytime
Andreas: I'm presenting as chair of the DVB task force on accessibility.
… I brought up this topic 2 years ago at TPAC in Seville,
… and we published. The main question I have for this part is if this group,
… who is one of the few groups with subtitling experts in a standards organisation
… wants to contribute and finding a way to align.
Andreas: [shows slides]
… DVB-I is the context.
… It is a way to unify TV services over IP with broadcast.
… DVB-I service discovery and content specification makes use of data models
… in TV-Anytime, which can also be used for other purposes.
… It defines metadata for TV content.
… Last time I detailed what accessibility setting metadata we would like to add to TV-A,
… and we got feedback and implemented it.
… Brief detail on one of them.
… For each accessibility feature of component we have a wrapper element like subtitles,
… audio description attributes, signing and others.
… For subtitles we have properties, like encoding (TTML, WebVTT etc), how it is carried
… (ISOBMFF, open, etc) but the point of interest here is what is the purpose, what kind of
… subtitle is it.
… Last time people didn't really understand fully, or saw some complexity.
… Although we know that for some stakeholders it may not be sufficient we made a basic
… set of values, defined in an XML classification scheme called SubtitlePurposeCS.
… 5 values: translation, hard of hearing, audio description, content related commentary and forced narrative.
… 2 questions: 1. Is it something this group would be interested in extending or working on?
… 2. Maybe it is already sufficient and all we need.
… I wanted to bring it back and see if there is interest in this.
… It's also based a bit on IMF, because of Pierre's proposal.
Pierre: The only difference is karaoke which might not be relevant for the target application.
… Another one that may not be relevant is chapters.
… Are there definitions?
Andreas: Yes, but I didn't go into detail here.
… For example transcription - maybe there is insufficient description.
… Because it only describes it as translation from one language to another,
… and not intralingual subtitles.
Cyril: I was going to say: transcription?
Andreas: Yes, but this would not only be same language, but also that it is accurate,
… verbatim transposition of what is said, right?
… How would you describe transcription?
Cyril: I was more thinking of DAPT, right
Andreas: yes, that's true.
Nigel: We did a lot of work in DAPT with represents - transcription could be
… dialogue or text in the video image, say. There's an extra layer of detali.
Andreas: We also thought about transcription, how AI transcription is different from hard of hearing
… or translation.
Pierre: Looks good to me
Cyril: I was checking the EBU-TT classification scheme metadata.
… How is this different? That already describes similar things.
Andreas: Yes it's a good point, and other subtitle standards may have this.
… But it's valid because the EBU-TT metadata is independent of the format.
… You may be able to use the EBU-TT metadata to classify the types of other formats of subtitles.
Nigel: It's just a classification scheme
Andreas: Yes, okay, we should look at it and align it.
… You're right, the context was different but I think we have not looked at it.
Cyril: At least having a correspondence between the two schemes.
Andreas: Yes
Cyril: In the US people make the distinction between closed captions and subtitles for the hard of hearing.
… There is gradually more text describing non-dialogue.
Pierre: That's news to me!
… It's the first time I am hearing that it's a different kind rather than a different style of authoring.
Cyril: I need to check my source.
Nigel: What is the distinction? Is it that closed captions don't have non-dialogue sounds?
Cyril: What I heard is that subtitles don't have any ambient sound description, then you add
… some to get closed captions, then add even more for hard of hearing subtitles.
… More context.
Nigel: It's a first for me as well!
Cyril: Probably safe to ignore it
Pierre: Another place to look for different types is DASH.
… There was an effort to create a mapping between IMF, DASH and others.
Andreas: We are mapping between DVB specifications - the DVB DASH specification might differ
… from DASH-IF, if that has its own metadata e.g. for the role attribute.
… What would be good anyway is if we for example, from the values, cover the spectrum of
… what we deliver. A mapping document, even an informative one, to map between the different
… specifications would be useful.
Pierre: I'm 99% sure I've seen that document somewhere. I feel like I've seen a spreadsheet...
Andreas: That would be good.
… Then it could either be extended or pointed to.
… It would be good to get at least a common understanding of the purpose and kind of subtitles,
… so we are sure we mean the same thing.
… What I get from your feedback is that it most likely covers what is already used
… apart from transcription that could be added.
… But then there could be different understandings of the labels or names.
… It would be good for us to look at it from the DVB side.
… I don't know where this could be worked on or published, the mapping between the different specifications.
… It could be actually some work in the CCSubs group.
… It doesn't need to be a standard document.
Pierre: Yes.
Andreas: Possibly there is no further need to work on it.
Nigel: Are all the accessibility features in the DVB Accessibility Implementation Guidelines
… that need a timed text track represented by this list?
Andreas: That cross referencing is something we want to do.
Pierre: There's a difference between what could be used and what is actually used today
Andreas: We tried to focus on what is used today
… In the liaison we sent to TTWG we include a classification that may not be deployed yet
… or have a label, so it is more future looking.
Pierre: I can definitely see a super simple web page with a column for each spec,
… DVB, HTML, IMF etc
Andreas: That would be a good target.
… It could just be a GitHub Markdown thing
Pierre: We could put that together very quickly.
Subtitle formats
Andreas: We reached a kind of status where two formats co-exist, that
… possibly on both side was a result of a kind of resignation that they are both in the market
… and will remain.
… What I hear constantly and from other stakeholders not in standards orgs is that they are
… really confused about these different formats and profiles.
… If they are not very involved they would like one format, and they don't mind which one.
… W3C or TTWG, maintaining both of them, does not deliver a clear answer to why we have
… this situation and how implementers in the domain should behave on that.
… It is hard to understand why you have two formats that implement the same kind of requirements.
… My question is what can we do, or the other way around, we should do something to ease
… the situation in the market, or find a position or strategy how to deal with this.
… I think this is our responsibility to do that.
Eric: To do what exactly?
Andreas: To explain to the market what they should do and why we have two different things
… coming from the same group in the same organisation.
Nigel: I presented a very short presentation two weeks ago at Demuxed addressing the
… same question, "What timed text format should I use?"
… I told the audience to use IMSC Text for new subtitle and caption applications, and
… DAPT for new transcription and audio description applications,
… though I did not have time to explain all my rationale.
… If you look at CMAF for example, and lots of other video systems, they all point to IMSC,
… so the web is the outlier here.
Eric: You haven't been able to convince browser vendors to implement [TTML] for over 10 years.
Andreas: Right, but the other spec is still not a recommendation.
Pierre: Javascript, HTML and CSS is too good Eric!
Eric: It works too well up to a point, and then there are issues like user privacy
… where we run into a wall.
Pierre: This is too casual
Eric: OK, how do we have a real discussion, where are we going to have it,
… who needs to be in the room and how are we going to have a decision?
Andreas: What I wanted to aim for is not a certain answer to the question.
… I just said that it would be good to have a strategy that I would expect for a standards organisation.
… If we were a company I'm sure we would have a statement or a strategy, but at the moment
… we don't have anything like that, we just move on, and that is unsatisfying.
… We all may have our own opinions on that.
… As a group it would be good to have help or an explainer to the world what they should do.
Nigel: One of the issues I see is that the same companies that are browser vendors have
… directly contradictory statements for their native frameworks - both Apple and Google, for example.
Eric: You need to make a case for adding support for IMSC to browser implementers.
… Browsers are the largest target. Not to disparage any of the other code on the system,
… but any code that you add to the browser has to be much more robust than ...
… I think people underestimate how much effort it is to add support for a complicated
… sophisticated feature to a browser, because of the security considerations.
… So what we need to do if it is important to add native support for IMSC to the browsers is
… to convince the browser vendors to spend a serious amount of time and money adding this
… feature.
Pierre: I agree that it's an investment and it's not instantaneous.
… On the security surface, this is not like implementing a new video decoder or encoder.
… It can be done entirely with CSS, HTML, JS. There's already an XML parser somewhere in all
… browsers. It is true that it is effort, and I don't want to minimise that.
… But compared to a completely fresh video decoder the risk is lower, if anything because there
… is test content and a reference implementation.
… I have implemented it now in a couple of languages.
Eric: Including C++?
Pierre: No, in JS + HTML + XML + CSS. I don't think you'd have to write a single line of C,
… maybe for binding at a super high level in the case of Webkit.
… Some operators have clients that entirely use polyfills.
… I'm happy to be proven wrong here, but I think this is true in the case of TTML.
Eric: That's not typically the way that a browser is written.
… Maybe I'm overstating things but it will be a major piece of work and investment.
Pierre: I totally agree with you on that one.
… There's already an XML parser in Webkit?
Eric: I assume there is but I don't actually know.
Pierre: Assuming that it exists, then writing in C, assuming the XML Parser is in C or C++
… or ObjectiveC then writing something that goes from XML to HTML + CSS then that's
… not hard. I would assume you do not have to write the layout engine too, and it would be more
… consistent and faster to use CSS for layout.
… So you could write the XML to HTML conversion in C and C++, which is not insignificant,
… but there's at least one very good example of doing that in JS, so writing the equivalent in C
… or C++ or whatever is pure logic - no layout, font rendering, no Unicode.
… If you told me that was the main obstacle then I could imagine people collaborating on it.
… If you said you also have to write the layout engine in C then that is a different business.
Nigel: There's also a reference Java implementation that maps TTML into SVG, which also
… has browser support, so that's also another approach, I'm not saying it's a good one or the right one.
Pierre: I'd be interested in considering what it takes to implement.
Eric: Every time you add a major feature which is what this is, there are trade-offs,
… and you have to convince browser implementers.
Pierre: I'm just trying to communicate that this would be worthwhile and not as hard as it might be.
Cyril: I was trying to understand where we're going.
… If I look at the Netflix experience, I can describe our workflow if it helps.
… We have two pipelines, live and VOD.
… In VOD, probably 90% of what we ingest is IMSC today.
… The rest would be legacy formats, SCC, STL etc.
… I'm pretty sure none of it is WebVTT.
… In the VOD space WebVTT is only present when we distribute content to Apple devices.
… The rest of our consumption on android or web, we deliver IMSC, and we control the players.
… The TVs have a Netflix SDK that handles TTML.
… We have very limited use of WebVTT except for iOS devices.
… For live, it's slightly different.
… In many workflows we still process 608 or 708 and convert to WebVTT because people
… think it's easier, but then we have to convert back to TTML to reach other devices.
… It's a pain to convert to 608 to WebVTT and then to TTML.
… If we have a way to migrate to one format we would be happy to do that.
… It's more likely TTML than WebVTT given our usage of TTML.
… I'm not even sure that adding a native TTML implementation would make us change our players.
Eric: That was going to be my next question.
… If a browser had native support for TTML I suspect you guys wouldn't use it because of
… your requirements for styling, and user profiles across devices.
Cyril: Yes, it would have to be configurable.
… When we were talking about FCC requirements, you seem to have requirements that
… are different from ours.
Eric: Sure, and Nigel you have said as much, that native support in browsers then
… you wouldn't use it for the same reason.
Nigel: BBC perspective is similar. We only distribute EBU-TT-D and IMSC Text subtitles,
… to all devices, and we don't have an issue doing live conversion of Teletext subtitles into
… IMSC using a commonly used off the shelf cloud based encoder.
… The blockers to adopting native playback are the ability to provide a good user experience
… including styling, and the lack of usage data, which is vital for product development, and
… is maybe a clue as to why browser implementers have generally not been interested in caption
… playback performance for many years.
Andreas: My intention was explicitly not to limit or focus the discussion on native
… implementation in the browser. You implied that we still have no solution for that.
… It could be part of the overall discussion and the solution.
… It would be good to know if W3C and TTWG is willing to make an effort to find an answer
… - if not, maybe we keep going as we are.
… But it's not good for the industry. If we would like to find an answer we need the right
… people in the room and a good place to discuss it. Usually TPAC is a good place.
… Only then in the discussion you decide whether to keep going with one format or adopt two formats,
… with justification of the decision, then there could be a new strategy.
… The question is if we want to face this and work on it and discuss it.
… Make some effort to find an answer together on that.
Pierre: Say that this obstacle you raise, that you're not convinced that if native IMSC support
… were implemented and you're concerned that people would not use it, do you think that is
… the main objection?
Eric: I don't know that it's the main objection.
… When anybody evaluates whether it is worth the cost to spend the time and cost to implement
… a feature you have to weigh all the options, is it better for our customers or would our time be
… better spent on some other feature - there's always a bottomless list of things to be done.
Pierre: Sure, absolutely.
Cyril: Take as an analogy the AV1 image format.
… It was adopted by browsers only because there was a library
… that became a reference implementation and then a few browsers used it.
… I wonder if we can think of it in a similar way for TTML or WebVTT.
… What if we have a library like that that converts whatever comes in into HTML with hooks
… to be able to do application specific styles or OS specific styles like in iOS etc.
… I wonder if that's a viable thing that would help?
Nigel: Feels like a good thought
Nigel: Thank you for raising this Andreas. It's good to be explicit about it.
… I don't think we would solve it in one meeting.
… My view working on this for so many years is that the web platform is failing the audience
… in ways that other platforms don't.
Hiroki: [speaks, scribe unable to follow, requested he post directly into IRC]
<hiroki3> I really welcome discussions around schemas like this. They are important both from an Accessibility perspective and for exploring the technical feasibility of generating and managing such data.
<hiroki3> broadcasting will have better alignment with Web Standards
<hiroki3> However, I would also like to gain a clearer understanding of which group should lead these discussions and what kind of outputs would be most desirable.
Atsushi: His interest is in how the DVB definition is related to the TTWG work.
… The schema could be attached to DAPT or audio description files.
… How could the DVB-I schema be used with TTWG work. The platform should be coordinated.
… From another perspective what is the place where the DVB-I schema will be applied?
Hiroki: I also know various groups strategy where the group members pointed ...
Atsushi: In reality TTWG participants are from companies as well as SDOs like DVB who use TTML,
… like SMPTE or something else, so he is interested in how metadata will be placed within
… TTWG. TTWG focuses on file formats but in real use cases there should be several metadata schemas,
… so how does TTWG think such metadata takes a role in TTWG, or how TTWG participants are interested.
Nigel: It depends what the members tell us we need.
… We allow extensibility in our formats to add arbitrary metadata.
… For specific cases we add relevant metadata like in DAPT the content-descriptor.
… For metadata outside the file format, we can consider that. For example there was a request
… to add an Attributes block to VTT to make it easier to set the attributes on the HTML track element.
Hiroki: [scribe missed]
Atsushi: [briefly touched about whole pipeline processing using TTML or DAPT documents of video package]
Andreas: What you asked for is how these two specification activities relate to each other,
… with the definition of file format here in TTWG, and the metadata in DVB and TV-Anytime for
… example. I understand your question is if TTWG is dealing with how their file formats are
… used in the workflow. I think TTWG doesn't deal with that, but other organisations define
… how to use TTML in their workflows. We can discuss more offline.
TTML Profile Registry
Nigel: This is a WG Note at the moment.
https://
Nigel: It has a registry definition and a registry section, so in principle it meets the core
… requirements of a Registry Track document, aside from maybe some formatting.
… The discussion point is: should we convert it from a WG Note to a WG Registry document
… so its status is clearer within W3C.
Andreas: Maybe there are more important things to work on first given the benefit of
… changing is not so great.
… It is already quite clear.
Atsushi: I believe some of the Web Codecs registry has a similar shift from Note to Registry.
… So it should be possible.
… You need a companion Rec track document which this has.
… You need a format too, and a description of what the table is for.
… And how to update and who will be the custodian.
… Everything in this WG Note meets that so I believe a transition request should be fine.
… Not sure if we should start from Draft Registry or Registry.
… If the group wants to then we can issue the transition request.
… I agree that the benefit of changing track is not great.
… A WG Note can also have a streamlined publication - just merging to the repo could
… cause a new publication, so not much changes I suppose.
Nigel: OK, I agree, let's leave this as-is for now, and leave open the possibility of changing
… it in the future.
Atsushi: Just note, changing the track will not change the URL for /TR documents.
Nigel: Right, if it did change the URL then I would not do it!
Atsushi: So nothing will change - it is purely up to Chairs and Editors.
Joint meeting follow-ups and planning.
Nigel: Yesterday we had the joint meeting with MEIG.
… Is there anything to note?
Andreas: We discussed TextTrackCue, use cases for adding a more generic TextTrackCue with a
… constructor. One of them was also what we discussed today, to have an HTML fragment cue,
… that could be used with TextTrack. There was no strong result from the discussion.
… One browser member, Philip Jagenstadt was there - I understood that he delegated the
… responsibility to the subtitle experts, TTWG, for that.
Nigel: Yes, it was good that he attended and listened - he didn't take particular actions.
Andreas: There's a question about how much TTWG is involved or serves as a place for discussion
… if browser implementers want to consider subtitle and caption questions.
Nigel: Minutes for that will be published by MEIG.
Andreas: We also had a brief discussion on the European legislation on accessibility,
… and there are some issues regarding subtitles and captions.
… The question was if the IG should work on a report that identifies gaps in web standards
… to satisfy those kinds of issues.
… There's no particular action for TTWG.
Nigel: I agree.
… On Thursday we have another joint meeting, with MEIG and APA WG.
… What do we want on the agenda for that?
… I'm assuming that we will cover the DVB Accessibility Implementation Guidelines from the
… incoming liaison that went to APA WG as well as TTWG.
… We should summarise the discussion we had this afternoon too.
… (on the subtitle format support)
… I'd like to provide an update on DAPT and IMSC 1.3 to APA and check if there are any
… requirements that they are hoping we support - especially the comment on IMSC as part of the
… wide review should be discussed.
… Also, coming out of the breakout session yesterday on accessible standards,
… and Matt Atkinson mentioned a new ARIA Notifications API, which could be relevant for
… sending subtitles and captions to screen readers, maybe in a standard way.
… At the moment the BBC puts an aria-live "polite" attribute on subtitles, but it's not obvious that
… is always the best choice for all users.
… I'll try to format this in some sensible way and send it before the meeting.
Process feedback
Nigel: Do we have any feedback now?
Andreas: Possibly we can open this as a topic on a future call, when more people who might have a view will be present.
Nigel: Good idea.
Wrap up and next steps
Nigel: Thanks everyone for attending today.
… We have good forward momentum for IMSC 1.3 and DAPT, and some actions to move ahead.
… I think we need some follow-up with Dana and Gary about the WebVTT tests
… review work. Dana told us yesterday that they've been meeting every 2 weeks, but that's
… not been visible to TTWG at all, so we should make that work more visible and transparent to
… all, rather than keeping it in a "quiet" repository.
… We made a bit of progress on WebVTT issues but more is needed.
… We had an interesting API presentation from Apple, but it's not really clear that the API is
… in scope of TTWG, however we are of course able to discuss it and provide feedback.
… We got some feedback on the TV-Anytime subtitle purpose field.
Andreas: There were some suggestions for additions and agreement that the mapping
… between different specifications, and what kind/type/purpose exist, but the document does
… not need to be prepared by this group.
Nigel: Of course it can be, it could easily be a WG Note.
Andreas: That's true.
Nigel: That could be useful if we want to propose changes to the kind attribute, for example.
Andreas: We can check the different options and choose a lightweight process.
Nigel: And we spent a good amount of time thinking and discussing how we can make the
… subtitle format landscape easier for users and content providers to navigate.
Nigel: With that, I think we're done for the day. Thanks again everyone.
… [adjourns meeting]