Satisfying formal requirements in the charter for the CR transition in the WG

we " • Should address the Media Accessibility User Requirements.” https://www.w3.org/TR/media-accessibility-reqs/

I believe that the applicable ones are [CC-x] and possibly [ECC-x]. Drafts below. Comments?

[CC-1] Render text in a time-synchronized manner, using the media resource as the timebase master. 
 - satisfied

[CC-2] Allow the author to specify erasures, i.e., times when no text is displayed on the screen (no text cues are active). 
 - satisfied

[CC-3] Allow the author to assign timestamps so that one caption/subtitle follows another, with no perceivable gap in between. 
 - satisfied

[CC-4] Be available in a text encoding. 
 - satisfied

[CC-5] Support positioning in all parts of the screen - either inside the media viewport but also possibly in a determined space next to the media viewport. This is particularly important when multiple captions are on screen at the same time and relate to different speakers, or when in-picture text is avoided. 
 - satisfied, but the captioning area has to be part of a media viewport. It’s not legal to paint outside ones viewport.

[CC-6] Support the display of multiple regions of text simultaneously. 
 - satisfied

[CC-7] Display multiple rows of text when rendered as text in a right-to-left or left-to-right language. 
 - satisfied

[CC-8] Allow the author to specify line breaks. 
 - satisfied

[CC-9] Permit a range of font faces and sizes. 
 - satisfied

[CC-10] Render a background in a range of colors, supporting a full range of opacity levels. 
 - satisfied

[CC-11] Render text in a range of colors. The user should have final control over rendering styles like color and fonts; e.g., through user preferences. 
 - satisfied

[CC-12] Enable rendering of text with a thicker outline or a drop shadow to allow for better contrast with the background. 
 - satisfied (possibly only in CSS UAs?)

[CC-13] Where a background is used, it should be possible to keep the caption background visible even in times where no text is displayed, such that it minimizes distraction. However, where captions are infrequent the background should be allowed to disappear to enable the user to see as much of the underlying video as possible. 
 - satisfied, under author control

[CC-14] Allow the use of mixed display styles— e.g., mixing paint-on captions with pop-on captions— within a single caption cue or in the caption stream as a whole. Pop-on captions are usually one or two lines of captions that appear on screen and remain visible for one to several seconds before they disappear. Paint-on captions are individual characters that are "painted on" from left to right, not popped onto the screen all at once, and usually are verbatim. Another often-used caption style in live captioning is roll-up - here, cue text follows double chevrons ("greater than" symbols), and is used to identify different speakers. Each sentence "rolls up" to about three lines. The top line of the three disappears as a new bottom line is added, allowing the continuous rolling up of new lines of captions. When displaying captions using the paint-on style, it is important to ensure that the final words that are displayed are visible for enough time for them to be read.
 - paint-on is an artefact of old caption-creation and delivery systems. VTT and modern systems can emulate paint-on, but cues are delivered as a unit, not character-by-character

[CC-15] Support positioning such that the edge of the captions is a sufficient distance from the nearest screen edge to permit readability (e.g., at least 1/12 of the total screen height above the bottom of the screen, when rendered as text in a right-to-left or left-to-right language). 
 - satisfied

[CC-16] Use conventions that include inserting left-to-right and right-to-left segments within a vertical run (e.g. Tate-chu-yoko in Japanese), when rendered as text in a top-to-bottom oriented language. 
 - satisfied

[CC-17] Represent content of different natural languages. In some cases the inclusion of a few foreign words forms part of the original soundtrack, and thus needs to be so indicated in the caption. Also allow for separate caption files for different languages and on-the-fly switching between them. This is also a requirement for subtitles. See also [CC-20]
 - satisfied

[CC-18] Represent content of at least those specific natural languages that may be represented with [Unicode 3.2], including common typographical conventions of that language (e.g., through the use of furigana and other forms of ruby text). 
 - satisfied

[CC-19] Present the full range of typographical glyphs, layout and punctuation marks normally associated with the natural language's print-writing system. 
 - satisfied to the extent Unicode does this.

[CC-20] Permit in-line mark-up for foreign words or phrases. 
 - satisfied

[CC-21] Permit the distinction between different speakers. 
 - satisfied

[CC-22] Support captions that are provided inside media resources as tracks, or in external files. 
 - satisfied; webVTT can be delivered as a text file, or as a track in an MP4 file

[CC-23] Ascertain that captions are displayed in sync with the media resource. 
 - satisfied

[CC-24] Support user activation/deactivation of caption tracks. 
 - this is a feature of the system that displays 

[CC-25] Support both edited and verbatim captions when available. 
 - this is a question of labelling caption streams in the encapsulating environment

[CC-26] Support multiple tracks of foreign-language subtitles including multiple subtitle tracks in the same foreign language.
 - this is a feature of the environment

[CC-27] Support live-captioning functionality.
 - satisfied; VTT files can be delivered line at a time, if needed, as there are no ‘bracketing’ constructs

[CC-28] Enable the bounding box of the background area to be extended by a preset distance relative to the foreground text contained with that background area.
 - satisfied


[ECC-1] Support metadata markup for (sections of) timed text cues. 
 - satisfied

[ECC-2] Support hyperlinks and other activation mechanisms for supplementary data for (sections of) caption text. 
 - satisfied

[ECC-3]Support text cues that may be longer than the time available until the next text cue, thus providing overlapping text cues. In such instances, users should be enabled to decide whether they prefer to see overlapping text, or automatically shorten display time, or to have the media resource paused while the caption is displayed. Timing should be provided by the author, but the user should always be able to override the author's timings.
 - satisfied, but there is no practical way for users to override timings in any caption system known

[ECC-4] Support timed text cues that are allowed to overlap with each other in time and be present on screen at the same time (e.g., those that come from the speech of different individuals). Also support timed text cues that are not allowed to overlap, so that playback will be paused in order to allow users to catch up with their reading.
 - satisfied

[ECC-5] Allow users to define the reading speed and thus define how long each text cue requires, and whether media playback needs to pause sometimes to let them catch up on their reading. 
 - this is a feature of the player rather than the caption expression language

David Singer
Manager, Software Standards, Apple Inc.

Received on Tuesday, 9 January 2018 23:00:57 UTC