{Minutes} TTWG Teleconference 2025-03-27

Thanks all for attending today’s TTWG call. Minutes can be found in HTML format at https://www.w3.org/2025/03/27-tt-minutes.html


In plain text:

   [1]W3C

      [1] https://www.w3.org/


                Timed Text Working Group Teleconference

27 March 2025

   [2]Previous meeting. [3]Agenda. [4]IRC log.

      [2] https://www.w3.org/2025/03/13-tt-minutes.html

      [3] https://github.com/w3c/ttwg/issues/303

      [4] https://www.w3.org/2025/03/27-tt-irc


Attendees

   Present
          Chris_Needham, Cyril, Gary, Matt, Nigel, Pierre

   Regrets
          Andreas, Atsushi

   Chair
          Gary, Nigel

   Scribe
          nigel, cpn

Contents

    1. [5]This meeting
    2. [6]DAPT
         1. [7]CRD auto-publication
         2. [8]Test suite
    3. [9]IMSC 1.3
         1. [10]forcedDisplay and visibility="hidden" w3c/imsc#484
         2. [11]Image Profile deprecation?
    4. [12]Meeting Close

Meeting minutes

  This meeting

   Nigel: Today's agenda: DAPT, IMSC 1.3
   … Is there anything else to add, or points to make sure we
   cover?
   … I'd like to cover the Image Profile removal from IMSC 1.3
   that we discussed.

   nothing more

  DAPT

    CRD auto-publication

   Nigel: A how-we-work thing
   … In WD phase, whenever we merged a PR to main, we
   auto-published a new WD
   … Now we're in CR, that's been fixed up so we publish a new CRD
   whenever we merge a PR to main.
   … Just checking in really that everyone's happy with that.
   … e.g. we published a CRS (snapshot) on 11th March, then I
   merged the PR that introduced
   … the XSD on 21st March we auto-published a CRD (draft).

   Cyril: No problem pushing changes - does it impact the earliest
   CR exit date?

   Nigel: No it doesn't.
   … However it's a good question, will check offline. Could be
   that we can
   … only request CR exit from a CRS, and if a CRS requires a new
   exit date then it might have that impact.

   Cyril: We shouldn't change the process we have, to publish as
   soon as we make changes.

   Nigel: +1
   … I hear no objections, let us continue with the current
   working mode.

    Test suite

   Nigel: We need to populate the test suite.
   … Too much process/good idea to raise an issue on the test repo
   … for each feature we need to add a test for, so we can track
   progress in completing the test suite?
   … (actually multiple tests per feature probably)

   Cyril: I have no problem with that

   Nigel: I'll go ahead and do that
   … on the dapt-tests repo
   … On the tests front again, I think almost all the tests will
   be validation ones because
   … the playback or presentation features are all in TTML2.
   … So I think we will end up having a valid input and an invalid
   input for each feature
   … and try to make the stimuli as narrow as possible to test
   that one feature. Sound about right?

   Cyril: Yes

   Nigel: Any more on DAPT?

   nothing more

  IMSC 1.3

   Nigel: Nothing showing on the agenda

   Pierre: We should look at #44 and work out when we are starting
   the clock on dropping Image profile

    forcedDisplay and visibility="hidden" [13]w3c/imsc#484

     [13] https://github.com/w3c/imsc/issues/484


   github: [14]w3c/imsc#484

     [14] https://github.com/w3c/imsc/issues/484


   Pierre: There's a lot of reading there, going back half a
   decade.
   … My summary:
   … Two issues, one that we fixed recently with revising prose.
   … Another which is a much deeper issue about the relationship
   between visibility and
   … screen readers - either we will do something, or close it or
   defer it.
   … It's a much bigger issue.
   … We addressed part of it in #593 to change the prose for
   forcedDisplay to be clearer about its
   … relationship with tts:visibility.
   … But you raised a much deeper issue about the relationship
   between tts:visibility and screen readers.
   … Ultimately, is there an urgent problem to solve for IMSC 1.3?

   Nigel: The use case hasn't gone away

   Pierre: That's why I'm not suggesting we close it, but defer it
   until we are ready

   Nigel: The use case is to provide a text alternative to text
   burned into the video image but absent from the soundtrack.

   Pierre: Forced Display is a good example - instead of using it,
   people just create two tracks.
   … Conceivably what you're providing could be just another
   track.

   Gary: Apple has that concept in HLS, where you can specify a
   track as being forced or not,
   … and in the guidelines I believe they say that the caption
   content should include the forced text.

   Pierre: The reason people split forced vs non-forced tracks is
   that you get more editorial freedom
   … to change the non-forced text - it could be similar here.
   … It might simply be that this is not the right time to solve
   the bigger issue.
   … But just having a separate track and signalling it could be
   enough.

   Nigel: It's interesting because you could argue that something
   like DAPT could be a good alternative. The styling is
   unimportant, as the intent is never to display it
   … Then the question is if there's ever a point in displaying
   the text. If not, we can close this IMSC issue. They can
   provide a different text track and use that instead

   Pierre: Write that down, disseminate it, and see what the
   response is. HLS has a force narrative track type. We just
   discussed an option to introduce a new track type

   Gary: There's an HTML issue for a new 'kind', also discussion
   of whether it should be a separate attribute, as forced is
   separate to the kind.

   <gkatsev> [15]html issue on kind=forced

     [15] https://github.com/whatwg/html/issues/4472


   Nigel: The goal of this is to have tracks that are only
   rendered via assistive technology. They could be rendered by
   script in the page, via Web Speech, or an aria live region

   Pierre: The difference between what you're proposing and
   forced, is you don't want it to be displayed as it's already in
   the content - for specific languages
   … So your point is you don't want it to be displayed on the
   screen in English because it's already on the screen. But
   someone with a screen reader can't see the display

   Nigel: Yes

   Pierre: That's exactly what forced narrative is. It works when
   the player-selected language is different from the ** language.
   What's different in what you're proposing?

   Nigel: The language in the media is not the same as the
   language you selected. We'd want to expose the text
   alternative, still in the same language, but make available to
   assistive tech.

   Pierre: Could be a player issue, a player connected to a
   screenreader could always play the forced narrative track
   … The player logic is: if narrative track is English, and the
   user preference is English, don't display it
   … Because you can already read the text on the screen
   … The same player could decide to send the forced display to a
   screen reader

   Nigel: Web players don't know if assistive tech is involved
   … It's a platform decision not to expose use of assistive tech

   Gary: The player can make it available to screenreaders if the
   audio language is different

   Pierre: Exactly

   Gary: The only downside is native video elements don't make
   text tracks available to screenreaders

   Pierre: That's a perennial issue...
   … So may not need additional signaling in the content as it's a
   player issue

   Nigel: The player needs to know if it's the kind of text track
   that should never be displayed on a visual display, or should
   be in a forced narrative scenario

   Pierre: I think the forced narrative track solves your problem.
   It's just different in the case of a screen reader vs a display

   Nigel: I'm thinking through the different permutations

   Pierre: Forced narrative is trying to solve the problem where
   someone can't read what's on the screen because it's in a
   different language
   … The track describes it in the language of the viewer

   Nigel: I don't think that's what forced narrative is. It's for
   when the content is mostly Enlgish, then there's something in
   French, then there's no English translation burned in. It's
   forced but not part of the video image

   Cyril: [describes Netflix's definition of forced narrative]

   Nigel: That's good

   <cyril> [16]https://partnerhelp.netflixstudios.com/hc/en-us/

   articles/217558918-Understanding-Forced-Narrative-Subtitles

     [16] https://partnerhelp.netflixstudios.com/hc/en-us/articles/217558918-Understanding-Forced-Narrative-Subtitles


   Pierre: So someone with a screenreader will want to receive the
   translation if it's not their language

   Nigel: Yes

   Nigel: The behaviour now is that it gets rendered over the
   video. The behaviour i'm talking about is it's made available
   to assistive tech but not rendered over the video

   Gary: Question is if you'd have something in the screen reader
   text that's not in the forced narrative?

   Nigel: A video with just burned in text, so you dont' put it
   into any text track at the moment, but could provide text track
   for assistive tech

   Gary: Why not always make the FN track always available to
   assistive tech, regardless of whether it's visible or not
   … It doesn't need to be visible if the language of the FN and
   the language of the player match

   Pierre: Exactly

   Gary: That's not true ... if the FN has translations, e.g., a
   sign in French, you'd want it to show with English text

   Pierre: The track should semantically describe what's in it,
   and let the player decide
   … Need to understand the difference semantically between
   Cyril's definition and what would be this screenreader track

   Nigel: In DAPT we have 'represents' which is there to describe
   the semantic of the content
   … You can describe in-video text, then a player can make it
   available to a screen reader as an equivalent
   … So maybe we've solved this from the DAPT perspective

   Gary: The HTML spec description is to treat it like the
   metadata type, where you have to handle it yourself
   … Could be an extension for descriptions, where the
   descriptions track is always made available to screenreaders

   Nigel: This brings us back to representing this at the track
   level, external to the document. I don't have other suggestions
   for signalling that's needed

   SUMMARY: If a scheme external to the timed text document
   contents can be used by players to decide what to expose to
   assistive tech, consider closing this issue with no action in
   IMSC, looking at forced narrative as an example.

    Image Profile deprecation?

   Nigel: Pierre and I drafted an outgoing liaison message to say
   we're thinking about dropping the image profile in IMSC 1.3

   github: [17]w3c/imsc#600

     [17] https://github.com/w3c/imsc/issues/600


   Nigel: Are we happy with the proposed text?

   Pierre: Let's plan to review
   … I was waiting for you to say you're done

   Nigel: I'll double check and come back to you. Could follow up
   tomorrow

   SUMMARY: @nigelmegitt to make sure the action to draft text is
   complete and then to send it.

  Meeting Close

   Nigel: Next meeting April 10. I'm on vacation, so regrets from
   me. Should we go ahead regardless?

   SUMMARY: Thanks everyone, let's adjourn. [adjourns call]


    Minutes manually created (not a transcript), formatted by
    [18]scribe.perl version 244 (Thu Feb 27 01:23:09 2025 UTC).

     [18] https://w3c.github.io/scribe2/scribedoc.html