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>
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>
Cc: John Foliot <john.foliot@deque.com>, Mention <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

Advancing the mission of digital accessibility and inclusion