Re: [w3c/imsc] APA comment: presentation customisation (#316)

Suggestion: perhaps we should attempt to put a stake in the ground now?

Nigel, what about Feb. 21st? Would that work for your group? Perhaps you
could check on your call this Thursday, and get back to us?

Thanks in advance.

JF

On Tue, Feb 6, 2018 at 12:57 PM, Janina Sajka <janina@rednote.net> wrote:

> Hi, Nigel, John:
>
> Just wanted to chime in and note that I am tracking this conversation
> and the suggestion of a joint telecon sometime soon at the usual APA
> hour, 12PM Boston, which is 5PM London.
>
> I'm thinking later in the month, perhaps the 21st or 28th? Some other
> Wednesday? Things get a little tricky in March because of CSUN
> conflicts.
>
> Best,
>
> Janina
>
> Nigel Megitt writes:
> > Hi John,
> >
> > Thank you for that. I'll check with the TTWG in our weekly call
> (Thursdays, 10am Boston === 3pm UK time) to see when would be a good time
> to schedule a meeting. I would guess that 5pm London on a Wednesday is
> likely to work for many of the members, subject to confirmation, so it may
> be a matter of choosing which Wednesday.
> >
> > One further point that may be worth reiterating: IMSC defines a profile
> of TTML for the application space of subtitles and captions. That means
> that in the main it is a subset of TTML, although it does include some
> extensions that users have found to be helpful. My reason for pointing this
> out is that I think the TTWG would likely consider significant changes,
> such as structural ones, to be beyond what they would be prepared to make.
> >
> > Kind regards,
> >
> > Nigel
> >
> >
> > From: John Foliot <john.foliot@deque.com<mailto:john.foliot@deque.com>>
> > Date: Saturday, 3 February 2018 at 00:36
> > To: W3C WAI Accessible Platform Architectures <public-apa@w3.org<mailto:
> public-apa@w3.org>>, Nigel Megitt <nigel.megitt@bbc.co.uk<mailto:
> nigel.megitt@bbc.co.uk>>
> > Subject: Fwd: [w3c/imsc] APA comment: presentation customisation (#316)
> >
> > (Reference: https://github.com/w3c/imsc/issues/316#issuecomment-
> 362651227)
> >
> > Hi Nigel,
> >
> > Thanks for the expansive reply. Certainly lots to mull over here. I am
> forwarding this response to the APA mailing list, where we might want to
> think on this a bit, but I agree that a joint call would likely be
> beneficial. I will leave it to Janina (our Chair) to arrange specifics, but
> traditionally our group meets for telecons at Noon Boston time on
> Wednesdays (5:00 PM London UK time). Would that time frame work for you
> over the next two weeks? (just in case next week is too soon to schedule
> something)
> >
> > At any rate, I look forward to further chatting.
> >
> > JF
> >
> >
> > ---------- Forwarded message ----------
> > From: Nigel Megitt <notifications@github.com<mailto:
> notifications@github.com>>
> > Date: Fri, Feb 2, 2018 at 6:16 PM
> > Subject: Re: [w3c/imsc] APA comment: presentation customisation (#316)
> > To: w3c/imsc <imsc@noreply.github.com<mailto:imsc@noreply.github.com>>
> > Cc: John Foliot <john.foliot@deque.com<mailto:john.foliot@deque.com>>,
> Mention <mention@noreply.github.com<mailto:mention@noreply.github.com>>
> >
> >
> >
> > Hi John, thanks for the long and thoughtful response.
> >
> > There are some points that I would certainly debate further, but the
> main point I would make is that the specification defines how a conforming
> presentation processor will process the author's instructions to display
> the text at the right times. By definition, if a regime exists in which the
> user overrides the author's instructions for that user's own purposes, we
> are out of scope of the specification.
> >
> > The information about the text and the times is certainly present, and
> such a deliberately non-conforming processor is free to do what it wishes
> with any of the other presentation-affecting markup in the subtitle
> document. If we attempted to be prescriptive about how that should work, we
> would never cover all the scenarios, including those that you have
> highlighted and those that have not yet been thought of.
> >
> > Does this need saying in the specification? I'm not sure how useful it
> is.
> >
> > ________________________________
> >
> > Now to your questions and some points that I would like to respond to:
> >
> > ... You may cringe at the thought of captions taking up 60% of the
> viewport, but for some users, that may be what they both want and need, and
> so who should "win" that choice?
> >
> > Nobody is winning here. It's not that I'm cringing about the size of the
> captions, it is that I know from experience that the viewer is watching the
> whole programme not just reading the captions. You simply cannot take the
> captions in isolation when considering accessibility of AV content, at
> least in the most overwhelmingly common current usage. Also, as above, I
> don't think the spec says anything about the user overriding authored
> settings.
> >
> > Real-estate is also a concern directly linked to the actual physical
> size of the device
> >
> > From my research, I would say that this link is far from
> straightforward, especially in the common case of full screen viewing.
> >
> > Scenario 1: Using a Second Screen.
> > ...
> > it's not so much a matter of if, but rather when. Would you agree?
> >
> > No, I would not. All the evidence I have seen is that moving the
> captions further from the image of the people saying the words, or
> generally from the video content, impairs understanding, enjoyment and
> overall accessibility. I do not doubt that there are special cases where
> this scenario might work well for some people but I have seen no evidence
> at all from anywhere to suggest that it is something that people want to do
> or are likely to begin doing soon. I'm always keen to learn new things
> though!
> >
> > Scenario 2: Picture in Picture.
> > ...
> > there is nothing with the current technology that would frustrate the
> ability to do that. Would you agree to that as well?
> >
> > I would agree - there's nothing to prevent that. Is this comment
> targeted at IMSC? Is there a change that needs to be made to facilitate it
> in some way?
> >
> > Our desire then is that there is nothing in your spec that would
> frustrate the ability to do this with a time-stamped mark-up file
> >
> > Okay. Without wishing to be too confrontational, I'm not sure if your
> desire is satisfied! It seems not, but maybe this is a question of scope of
> the specification.
> >
> > As an example, content authors should avoid inserting hard breaks in the
> rendering, as it would introduce weird rendering if and when the text/font
> was enlarged (instead, the text should 'reflow' in the dedicated caption
> region, and ideally that region itself can "grow" to accomodate enlarged
> text).
> >
> > Perhaps the answer to this is that an enlarging presentation processor
> might treat any line breaks inserted as somewhat optional. This is
> certainly an implementation matter.
> >
> > ... content authors should avoid inserting hard breaks in the rendering
> ...
> >
> > For the general case of authored subtitles and captions there is
> certainly research (even some quite recent academic research I came across
> in November, which I cannot cite until it is published) showing that
> correctly positioned line and subtitle breaks (in relation to the grammar
> of the sentence) make a significant difference to how easily people can
> read and understand the text. I was unaware of this independent research
> until I saw it presented, and as it happened the author had taken as a
> hypothesis the BBC's subtitle guidelines regarding line breaks<
> http://bbc.github.io/subtitle-guidelines/#Break-at-natural-points> and
> validated those guidelines.
> >
> > My conclusion is rather strongly to say that authors should insert
> breaks in the rendering, because it makes the text more accessible in the
> majority case. As I said above, implementations that work against a
> different constraint set may choose to process those line breaks in
> out-of-spec ways, and that might be entirely reasonable.
> >
> > will users be able to enlarge caption text going forward, and can the
> spec leave open the possibility that on some systems, users will be able to
> find an accomodation spot that suits their needs?
> >
> > It might be ducking the question, but my view is you need to ask a wider
> set of implementers about this. If implementers wish to implement something
> that deliberately plays back the subtitle documents differently to the
> "locked down" interpretation of those documents defined by the
> specification, then users will have that option. The HBB4ALL project
> investigated exactly this, and provided users with the ability to present
> TTML based subtitles with customisation options beyond those defined in the
> specification.
> >
> > I would go further though - in practice most real world implementations
> vary somewhat from the specification to some degree. It's just that they
> don't all vary in the same way, so there is nothing to standardise at this
> time. I take this as evidence that the possibility is open for some systems
> to provide accommodations for particular needs.
> >
> > ________________________________
> >
> > an authoring note that suggests that author-supplied "rendering
> instructions" may be overridden by the end user, and so authors should
> avoid making assumptions about how the final rendering will look in all
> instances.
> >
> > Authors must make some assumptions, but I do not know of any who think
> they know how all the final renderings will look in all instances. I'm not
> even sure why they would expect to know this. They do need to know roughly
> how big the subtitles will be and where they will be positioned, and
> sometimes there is a surprisingly small window in which to place the text.
> If users generally expect to be able to change the text presentation
> arbitrarily without loss of meaning of the whole programme including the
> video, they are frankly wrong in many cases. Some transformations are much
> safer than others: for example a practice of authoring to a large size and
> allowing the user to shrink the text is much safer in this respect than the
> other way around.
> >
> > you never will know what the actual viewport size is for the web-content
> >
> > The situation is certainly different here: you have a pretty good idea
> what it is for video content, notwithstanding the additional scenarios you
> proposed.
> >
> > ________________________________
> >
> > On my list of general requirements, I intended that as food for thought
> for tackling this general thorny issue in the medium term, rather than with
> any intent to modify IMSC 1.1 in the short term.
> >
> > The privacy issue is not one for the subtitle document or the document
> format - it is that, were the user agent to make available the user's
> caption presentation preferences, say by an API, it would provide
> fingerprinting data to any script running on that UA. This is why some
> implementations go to great lengths to hide the settings and the final
> rendering from scripts.
> >
> > ________________________________
> >
> > if there is a need or desire to get your WG and APA together for a chat
> (teleconference) we can certainly look to arrange such
> >
> > Judging from this thread, I suspect that would indeed be helpful, and
> would be happy to participate and assist with the arrangements.
> >
> > Thanks again!
> >
> >
> > ​
> >
> >
> >
> >
> > --
> > John Foliot
> > Principal Accessibility Strategist
> > Deque Systems Inc.
> > john.foliot@deque.com<mailto:john.foliot@deque.com>
> >
> > Advancing the mission of digital accessibility and inclusion
>
> --
>
> Janina Sajka
>
> Linux Foundation Fellow
> Executive Chair, Accessibility Workgroup:       http://a11y.org
>
> The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
> Chair, Accessible Platform Architectures        http://www.w3.org/wai/apa
>
>


-- 
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion