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

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

Received on Tuesday, 6 February 2018 18:57:30 UTC