Accessibility/HTML5 captions v2: Difference between revisions

fixed typo
(fixed typo)
 
(5 intermediate revisions by the same user not shown)
Line 1: Line 1:
= Specification of the itext element (Second Version) =
= Specification of the itext element (Second Version) =
Comments:
GF= Geoff Freed, WGBH/NCAM


== Introduction ==
== Introduction ==


The [https://wiki.mozilla.org/Accessibility/Experiment1_feedback feedback on the first version] has encouraged a full work-over of the specification.
The [https://wiki.mozilla.org/Accessibility/Experiment1_feedback feedback on the first version] has encouraged a full work-over of the specification.
Please leave feedback on this second version at [https://wiki.mozilla.org/Accessibility/Experiment2_feedback https://wiki.mozilla.org/Accessibility/Experiment2_feedback].


A particular change is the introduction of a grouping-level element between the media element and the itext element. This has several advantages: the itext elements inside this element are regarded as alternative tracks for display in one region, only at most one of them can be active at any point in time, a default display style can be associated with them, and event handlers for entering and leaving a new element can be associated. The only disadvantage is that there are now two new elements rather than only one to extend an already large HTML5 specification.
A particular change is the introduction of a grouping-level element between the media element and the itext element. This has several advantages: the itext elements inside this element are regarded as alternative tracks for display in one region, only at most one of them can be active at any point in time, a default display style can be associated with them, and event handlers for entering and leaving a new element can be associated. The only disadvantage is that there are now two new elements rather than only one to extend an already large HTML5 specification.
Line 92: Line 90:
   visibility: hidden;
   visibility: hidden;
   aria-live: assertive;
   aria-live: assertive;
GF:  It's important to have a style option that reveals TAD, which would be useful for visually impaired viewers who prefer to both see and hear text.


CUE area:
CUE area:
Line 169: Line 164:
The src  attribute gives the address of the external itext resource. The value of the attribute must be a valid URL identifying a text resource of the type given by the type attribute, if the attribute is present, or of the type "text/srt", if the attribute is absent. This attribute is required to enable the user agent to pick the correct parser for the file, even if it only receives a "text/plain" resource.
The src  attribute gives the address of the external itext resource. The value of the attribute must be a valid URL identifying a text resource of the type given by the type attribute, if the attribute is present, or of the type "text/srt", if the attribute is absent. This attribute is required to enable the user agent to pick the correct parser for the file, even if it only receives a "text/plain" resource.


GF:  As I've stated before, I question the use of SRT as the default.
The type attribute gives the format of the data, RFC 2046. If the attribute is present, its value must be a valid MIME type, optionally with parameters. The type parameter must not be specified. (The default, which is used if the attribute is absent, is "text/srt".) [RFC2046]
 
 
The type attribute gives the format of the data, RFC 2046. If the attribute is present, its value must be a valid MIME type, optionally with parameters. The charset parameter must not be specified. (The default, which is used if the attribute is absent, is "text/srt".) [RFC2046]
 
GF:  Ditto.
 


NOTE: text/srt will need to be registered as a mime type (as well as a format standardisation)
NOTE: text/srt will need to be registered as a mime type (as well as a format standardisation)
Line 196: Line 185:


An activated itext resource displays its content into a specified screen area provided by the browser based on default styling. If the active itext resource changes, the text will change to originate from the new resource as soon as possible to the browser without interrupting any of its other display requirements (e.g. audio/video playback).
An activated itext resource displays its content into a specified screen area provided by the browser based on default styling. If the active itext resource changes, the text will change to originate from the new resource as soon as possible to the browser without interrupting any of its other display requirements (e.g. audio/video playback).
GF:  Is it possible to override the default settings of the browser?  How would this be accomplished?
What about displaying text in multiple regions simultaneously?  For example, French subtitles in the upper third and English captions in the lower third?  Or, as is not uncommon in broadcast captions, the display of two sets of captions simultaneously (e.g., when two people are speaking at the same time).
Also, what about providing both CC and TAD at the same time?  The use of one should not exclude the use of other.




Line 320: Line 303:


As the controls attribute in the video element is specified, this creates a menu with subtitles and spoken transcript as the submenu items to select from. Only one track can be activated at any point in time from within a itextlist. Also, an additional element of "none" should be added by the browser to allow to deactivate all itext elements.
As the controls attribute in the video element is specified, this creates a menu with subtitles and spoken transcript as the submenu items to select from. Only one track can be activated at any point in time from within a itextlist. Also, an additional element of "none" should be added by the browser to allow to deactivate all itext elements.
GF:  It would be useful to be able to activate more than one track at a time:  for example, to be able to display both English and German text simultaneously.  How would this affect the area occupied by the player?