Interop: Applying system accessibility preferences to WebVTT cues

[jernoble]

Safari and Chrome (on macOS) read system accessibility preferences and convert the user's preferred caption settings into CSS styles. These styles are then applied to the WebVTT cues rendered by the UA. Attached are examples of Chrome and Safari rendering with various accessibility preferences set.

Firefox (on macOS, at least) does not read system accessibility preferences.

Additionally, Safari and Chrome implement WebVTT rendering within the media element Shadow DOM, which is closed, and therefore inaccessible from the rest of the page. Queries of the type getComputedStyle(video, "::cue") fail to apply styles defined inside the Shadow DOM, which includes both system accessibility derived styles, as well as styles applied by the WebVTT file itself.

Concerns have been raised in PR #520 that UAs which apply users' system accessibility preferences to WebVTT rendering may cause fingerprinting issues due to exposing those users' distinguishing preferences to web content. Safari and Chrome's implementation details are intended to prevent that exposure, but they also introduce an interop issue.

Questions:

• Should the specification include a note regarding system accessibility preferences?
• Should the specification suggest or require those preferences to be hidden from the page?

Examples:

Default Caption Settings, Chrome Rendering, Safari Rendering:

Classic Caption Settings, Chrome Rendering, Safari Rendering:

Chrome Classic Caption Rendering:

Safari Classic Caption Rendering:

Custom Caption Settings, Chrome Rendering, Safari Rendering:

[nigelmegitt]

I suggest this might work well as a GitHub "discussion" rather than an issue - @gkatsev if you agree, maybe click the "Convert to discussion" button towards the bottom of the sidebar in the GitHub web UI? That would allow us to have separate threads for each question, for example.

[gkatsev]

yes, let's try it out.

[gkatsev]

Looks like WebVTT currently has a privacy and security considerations section. In it, under styling security, it mentions that only :before and :after are accessible via getComputedStyle(). It sounds like when that section was written that was the case but that since then pseudo-element support was added to getComputedStyle(). However, that section implies both that the spec intended this information to be private and that the spec should be updated to be explicit about it.

[gkatsev]

There was a concern raised about system preferences and page styling conflicting: #528 (comment)

Yeah two issues that immediately came to mind. For the example, let's say system a11y settings have effectively background-color: white and color: black.

Issue number 1 is causing unreadable backdrops on existing content. Let's say I have a dark video, so as an author unaware of these settings, I write:

video::cue {
 color: white;
}

This works if the backdrop is transparent, but a user with such settings would get white on white and unreadable text.

Is there any way to actually address this on the spec side outside a note saying "be careful of conflicting styles"?

I guess that's also one of the reasons why the new FCC ruling talks about previewability in place.

[emilio]

We could not apply ::cue colors if the user preferred backdrop is not transparent or something, but yeah it's a bit messy.

[nigelmegitt]

I think this a good example of why the currently implemented caption customisation model is over-simplistic. It also still does not deal with how to modify the presentation of subtitles and captions that make use of multiple colours.

My proposal is that instead of the current "override" customisation model, which might work for some users, there should be a "modify" model, where palettes can be adjusted or modified (e.g. desaturate by some variable amount, replace colour X with colour Y, scale the authored text size by some variable amount, i.e. retaining deliberately authored styling differences.