Styling Captions (was RE: VTT/CSS (was RE: Evidence of 'Wide Review' needed for VTT))

Jeroen Wijering wrote:
>
> Style rules in the header are most important IMO. They allow CC authors
> to style:
>
> *) All cues in a VTT
> *) Specific cues (using classes or ids)
> *) Specific persons or snippets (using voices or ids)
>
> I see inline styling as largely redundant to styling rules in the
> header (most can be achieved with classes, id's and voices).

+1

As authoring guidance (and I will ensure that the WCAG WG is brought into the 
loop) large organizations *could* (RFC 2119 MAY) provide information about 
those (reusable) classes as part of their larger site's "Accessibility Info" 
documentation, so that for those users who need/want to author custom CSS 
style sheets, they have the 'hooks' provided to them.

>
> > This should be achievable through UA configuration or even through
> > something like a greasemonkey script or user CSS which can override
> > styles dynamically in the browser."
> > (source: Media Accessibility User Requirements -
> > http://www.w3.org/WAI/PF/media-a11y-reqs/#VP-2)
> >
> > From a practical perspective, it is significantly easier for third
> > parties to write scripts and/or user style-sheets if the content is
> > all located in one-place. For this reason, I would suggest that CSS
> be
> > contained in a linked style sheet, and *NOT* written in-line in the
> VTT file.
>
> This is absolutely important, but I also see this also as a separate
> step. Overall there seem to be 3 tiers:
>
> First, there's the styling rules from the environment (HTML5 browser),
> which apply to all VTT files played. They're the baseline. General use
> cases are to make the captions look good and read well within the
> site/player design.

+1  Modifications at this level SHOULD be handled via UA user-settings. 
Question: should this be conveyed in the VTT spec, or elsewhere? David? 
Others?

>
> Second, there's the styling from the VTT author, which apply to only
> that single file. Use cases include emphasis on certain types of cues
> (music, voiceover, etc) and certain ranges of cues (e.g. repositioning
> when the default region overlaps with in-video text). It's preferred to
> have these rules live inside the VTT, as it makes for easier authoring,
> file management, conversion to other formats and implementation of
> parsers (outside of HTML browsers).
>
> Third, the end user can override the styles an author has set (or, more
> common, set additional rules). This is specific to the individual user
> and relates to the FCC options end users can set in video players. As
> David said, through CSS but more importantly system-wide menus
> (iOS/Android/etc) or options in the video player
> (YouTube/JWPlayer/etc).

Scenarios 2 & 3 SHOULD be modifiable by the end user. The means to make these 
modifications would likely best be integrated with the 'player', but could 
also be achieved through user style-sheets. However, given the complexity of 
creating user style-sheets, good players should offer a simpler means of 
making some basic changes (I am thinking, for example of font size, font-face, 
foreground and background colors as the most basic sub-set). While I can 
follow up with the appropriate WAI groups (likely WCAG WG and UAAG WG - the 
User Agent Accessibility Guidelines WG) I wonder again out loud whether this 
type of basic authoring guidance should be provided in the VTT spec itself. If 
there is a general feeling that this isn't a bad idea, David I would be 
willing to try my hand on a first-pass paragraph or two as non-normative 
content for the spec. Thoughts?

>
> In short, style rules in the header of a VTT file is what we (our
> publishers) would like to have. Styling rules inside the cues and links
> to external CSS are less relevant.

Thanks Jeroen, I think that a consistent approach to providing styling 
information will be critical, and this approach seems quite workable to me 
(for whatever that's worth LOL).

Cheers!

JF

Received on Wednesday, 21 January 2015 16:57:29 UTC