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

​> Treating the text in isolation in this use case is the fault I think.


It depends on the end-user, and their individual needs. I fear this may not
be the appropriate place, but here goes... :)

Might I suggest that there are some additional data points here worth
considering:

As previously noted, WCAG has this notion of Accessibility Supported
<https://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#uc-accessibility-support-head>,
which in essence says *if* the technology supports an accommodation method,
authors need to align to that (i.e. do nothing to frustrate the
accomodation method). Part of that concept states:

When new technologies are introduced, two things must happen in order for
people using assistive technologies to be able to access them. First, the
technologies must be designed in a way that user agents including assistive
technologies could access all the information they need to present the
content to the user. Secondly, the user agents and assistive technologies
may need to be redesigned or modified to be able to actually work with
these new technologies.


So, for example, we have a requirement that effectively states "Do not
disable Pinch-to-zoom" on mobile devices - obviously out-of-scope for
desktops (at least those that do not have a pinch-to-zoom display), but a
critical requirement on those devices that do support pinch-to-zoom.

Most importantly today however is that we are focused on the first part of
that quoted section: "*... the technologies must be designed in a way
that ...*"

Additionally, while I can appreciate your concern over suitable display
'real-estate', may I also resurface an old axiom often heard around the
W3C: "author proposes, user disposes"? One of the key things to remember
about "accomodation" is that the end-user traditionally understands there
is a trade-off, so what they *really*  need/want is the ability to decide
for themselves where their comfort level is in that trade-off. 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?

Real-estate is also a concern directly linked to the actual physical size
of the device: obviously this will be a greater concern on an iPhone than
on a 55" big-screen TV, yet we need to remain somewhat agnostic to that
fact, as we simply do not know how or what the end user will be using to
access the video.

But I also urge you to think a bit out-of-the-box.

We have discussed, with both this group as well as WebVTT, the concept that
for "TV" and other forms of large-screen/dumb-terminal displays, we
recognize the technical limitations of those technologies around
limitations in viewport size, etc. But additionally, we have been following
activities related to other "TV"[sic] work at the W3C, such as the Second
Screen activity.  And so, to your concern Nigel, a few "alternative" ways
of looking at this:

Scenario 1: Using a Second Screen. The family gathers in the great room to
watch a movie. Gramps, who is extremely hard of hearing, has a tablet which
he uses at the same time as the family is watching the 55" Big Screen TV.
Through a setting on his set-top box, the captions (aka time-stamped file)
are piped to his tablet, where he can either pinch to zoom, or otherwise
increase the text to a readable level on the tablet, allowing him to follow
along, without the whole family having to see the captions on the big
screen. While we've yet to see this type of accomodation emerge to-date (at
least commercially, that I am aware of), it is our understanding that the
technologies and means to do this are pretty much in hand today, so it's
not so much a matter of *if*, but rather *when*. Would you agree?

Scenario 2: Picture in Picture. Earlier this week, the US President gave
his State Of The Union address, which was broadcast live across many
networks. However, if you think about it, although this was broadcast on
TV, the key point was not watching the speaker speak, it was the content of
the speech, the audio track, that was most important. Imagine a setting
where, instead of overlaying the captions (z-index style [sic]) on top of
the video feed, that instead the 2 feeds could be piped to (essentially)
two screens again: render the text (enlarged as much as possible/desired)
in the main viewport, and then send the video feed of the speaker to the
smaller, picture-in-picture region. Once again, while I am unaware of any
system that is doing this today, it is our understanding that there is
nothing with the current technology that would frustrate the ability to do
that. Would you agree to that as well?

And so, two out-of-the-box scenarios that aren't total science-fiction,
just perhaps "forward thinking". 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; that yes, the technology *CAN* support these
ideas.

We fully recognize that this will have what many will perceive as an
adverse visual outcome, but we wish to assure you that that alone isn't the
deal-breaker. Rather, locking down captions so that they cannot be enlarged
to a readable size for the user is far more significant and troubling (and,
Nigel, with EN 301 459 looking to adopt WCAG 2.1 as their benchmark), this
may be cause for regulatory concern.

*So... putting aside 'display' concerns, 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?*

*************
To Pierre-Anthony's comment: "*I am not sure a note that would say
"consumer system may modify this at will" will really help.*"

I don't think that is what we are seeking. Rather, 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.

Think of it more in keeping with the Responsive Web thinking; that you
never will know what the actual viewport size is for the web-content, so
again, don't lock things down that could have a negative display outcome.
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).


To your list Nigel:

- Need for privacy - avoid user settings being fingerprinting vectors
     [JF] Agreed, but since this is a user-setting or configuration on the
end device, it is unclear how the time-stamped text file could communicate
sensitive data back to the source (not saying that some black-hat won't
try, but...)

- Need for ease of use - allow user to change settings directly in the
player
      [JF] Agreed, although again, I do not see this as a problem with the
current spec under discussion. Additionally, different players may have
different solutions (see my above), and so as long as there is nothing that
frustrates or forbids alternate renderings there should be no issue. The
set-up to consume those alternatives, while indeed needing to be "simple",
is out of scope here.

- Need for system defaults - allow user to change default settings
system-wide
      [JF] Agreed, see bullet 2

- Prevalence of sites implementing their own subtitle players rather than
using native players
      [JF] True enough, but that is a hardware concern as well. As long as
the content being consumed by the player has the appropriate 'hooks' or
*ability* to be rendered differently than how the author first proposed,
then the goal is being met. What we want (need) is that the ability for the
end-user to make those kinds of text-rendering adjustments is not
frustrated *by the spec*.

- Need for support in native players for all the formats that are needed
      [JF] Once again, a hardware concern. One of the import things to also
consider is that as WCAG is taken up by legislators around the planet, the
specifications there also drive development: it may not be the ideal way to
address the chicken and egg problem ("we don't have any players today that
can do this"), but is has proven effective. So again, as long as this can
be supported, we can wait for the rest of the ecosystem to mature.

- In the absence of native player support for all formats, the need for an
extensible model for player implementations that can take into account user
settings made locally or in the system defaults without those settings
being exposed
      [JF] Correct, and initially, I am expecting to see scripted solutions
come forth. Nigel, I do not share the same concern you seem to have about
exposing user-settings (not that this isn't a concern, just I am failing to
see how that would be a timed-text format concern).

At any rate, this is more of an email than a "issue" response, and 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.

Please advise.​

JF

On Wed, Jan 31, 2018 at 5:43 AM, Nigel Megitt <notifications@github.com>
wrote:

> However, it must be possible for the user to overwrite the author’s choice
> of font size, or background color, for example. This is necessary for
> accessibility reasons, in the same way that browsers allow the user to
> change font size and background color. How can we find a good solution for
> these conflicting interests between author and user? We would like to get
> into a discussion with you on this issue.
>
> This is a *very* tricky requirement to navigate from an implementation
> perspective. There are many approaches in use, and none of them seems
> completely satisfactory to me - we should continue to look for a better
> way. Amongst the conflicting requirements:
>
>    - Need for privacy - avoid user settings being fingerprinting vectors
>    - Need for ease of use - allow user to change settings directly in the
>    player
>    - Need for system defaults - allow user to change default settings
>    system-wide
>    - Prevalence of sites implementing their own subtitle players rather
>    than using native players
>    - Need for support in native players for all the formats that are
>    needed
>    - In the absence of native player support for all formats, the need
>    for an extensible model for player implementations that can take into
>    account user settings made locally or in the system defaults without those
>    settings being exposed
>
> (this list is probably incomplete!)
>
> These are format agnostic requirements. It is clear that a model of "you
> get all the goodies if you use our preferred format X" has failed in the
> marketplace because there is not widespread or universal agreement (yet) on
> an X that works for everyone.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <https://github.com/w3c/imsc/issues/316#issuecomment-361908217>, or mute
> the thread
> <https://github.com/notifications/unsubscribe-auth/ABK-c2YNV8dFopPtim40KIoYMwOzU_V6ks5tQFH7gaJpZM4RygnY>
> .
>



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

Advancing the mission of digital accessibility and inclusion