Refer to 2.1 Audio Description.

Audio descriptions (also known as video descriptions or simply descriptions) make visual media accessible to people who are blind or visually impaired by providing descriptive narration of key visual elements. These elements include actions, costumes, gestures, scene changes or any other important visual information that someone who cannot see the screen might ordinarily miss. Descriptions are usually timed and recorded to fit into natural pauses in the program-audio track. (See the section on Extended Descriptions for an alternative.) The descriptions are usually read by a narrator with a voice that cannot be easily confused with other voices in the primary audio track. They are written to convey objective information (e.g., a yellow flower) rather than subjective judgments (e.g., a beautiful flower).

As with captions, descriptions can be open or closed.

• Open descriptions are merged with the program-audio track and cannot be turned off by the viewer.
• Closed descriptions can be recorded as a separate track containing descriptions only, timed to play at specific spots in the timeline and played in parallel with the program-audio track.
• Some audio descriptions can be given as a separate audio channel mixed in at the player.
• Other options include a computer-generated ‘text to speech’ track (texted audio descriptions) - this is described in the next subsection.

Audio descriptions provide benefits that reach beyond blind or visually impaired viewers: e.g., students grappling with difficult materials or concepts. Descriptions can be used to give supplemental information about what is on screen—the structure of lengthy mathematical equations or the intricacies of a painting, for example.

Audio description is available on some television programs and in movie theaters in the U.S. and in some other countries; however regulation in the U.S. and Europe is increasingly focusing on description, especially for television, reflecting its priority with citizens who have visual impairment. The technology needed to deliver and render basic audio description is in fact relatively straightforward, being an extension of the common audio-processing solutions. Playback products must support multi-audio channels required for description, and that any product dealing with broadcast TV content provide adequate support for description.

Requirements

Systems supporting audio/video descriptions that are not open must:

• (AD-1) Provide an indication that descriptions are available, and are active/non-active.
• (AD-2) Render descriptions in a time synchronized manner, using the media resource as the timebase master.
• (AD-3) Support multiple description tracks (e.g., discrete tracks containing different levels of detail).
• (AD-4) Support recordings of real human speech as part of a media resource, or as an external file.
• (AD-5) Allow the author to independently adjust the volumes of the audio-description and original soundtracks.
• (AD-6) Allow the user to independently adjust the volumes of the audio-description and original soundtracks, with the user's settings overriding the author's.
• (AD-7) Permit smooth changes in volume rather than stepped changes. The degree and speed of volume change should be under provider control.
• (AD-8) Allow the author to provide fade and pan controls to be accurately synchronised with the original soundtrack.
• (AD-9) Allow the author to use a codec which is optimised for voice only, rather than requiring the same codec as the original soundtrack.
• (AD-10) Allow the user to select from among different languages of descriptions, if available, even if they are different from the language of the main soundtrack.
• (AD-11) Support the simultaneous playback of both the described and non-described audio tracks so that one may be directed at separate outputs (e.g., a speaker and headphones).
• (AD-12) Provide a means to prevent descriptions from carrying over from one program or channel when the user switches to a different program or channel.
• (AD-13) Allow the author and the user to relocate the description track within the audio field, with the user setting overriding the author setting. The setting should be readjustable as the media plays. [what is the difference to AD-8?]
• (AD-14) Support metadata, such as copyright information, usage rights, language, etc.

Accept this section?

Summary

Details

Refer to 2.2 Texted Audio Description.

Audio descriptions that are given as text rather than recorded voice create specific requirements.

Texted audio descriptions are delivered to the client as text and rendered locally by e.g. a screen-reader or through a braille device. This can have advantages for users who are frequent screen-reader users and are thus given detailed control of the preferred voice and speaking rate, and many more options to control the speech synthesis.

Texted audio descriptions are provided as text files with a start time for a description cue. Since the duration that a screenreader takes to read out a description cue cannot be determined during authoring of the cues, it is difficult to make sure they don't run over into the main audio or into other description cues. This is likely to be caused by at least three reasons:

• A typical author of textual audio descriptions does not have a screen reader. This means s/he cannot check if the description fist within the time frame. Even if s/he has a screen reader, a different screen reader may take longer to read out the same sentence;
• Some screen reader users (e.g. elderly and people with learning disabilities) may slow down the speech rate; or
• A visually-complicated scene (e.g. figures on a blackboard in an online physics class) may not be sufficiently described within any time interval in the original audio track.

Requirements

Systems supporting texted audio/video descriptions must:

• (TAD-1) Support to present a text audio description through a screen-reader or braille device with playback speed control and voice control and synchronisation points with the video.
• (TAD-2) Textual ADs or EADs need to be provided in a format that contains the following information:
  • start time, text per description cue (the duration is determined dynamically, though an end time could provide a cut point)
  • possibly a speech synthesis markup to improve quality or the AD (SSML or Speech CSS)
  • accompanying metadata providing labeling for speakers, copyright information, usage rights, language, etc.
• (TAD-3) Support to present a text or separate audio track privately to those that need it in a mixed-viewing situation, e.g. through headphones.
• (TAD-4) Support different options for the overflow case: continue reading, stop reading, pause the video.
• (TAD-5) Support the control over speech synthesis playback speed, volume, voice, and provide synchronisation points with the video.

Accept this section?

Summary

Details

Refer to 2.3 Extended audio description.

In some types of material the pace of delivery is such that there is insufficient time to represent all of the necessary information in the gaps in the existing audio. To meet this case, the concept of extended description was developed. This extends the overall playback time – typically by inserting pauses at key moments - and then uses the additional time to deliver longer descriptions. For technical reasons this has not been possible in broadcast television. However hard-disk recording and on-demand internet systems can make this a practical possibility.

Extended audio description (EAD) has been reported to have benefits for cognitive disabilities; for example it may be of benefit for Aspergers Syndrome and other autistic spectrum problems, in that it can make connections between cause and effect, point out what is important to look at, or explain moods that might otherwise be missed.

Requirements

Systems supporting extended audio/video descriptions must:

• (EAD-1) Support the use of extended descriptions with detailed user control.
• (EAD-2) Support automatically pausing the video and main audio tracks in order to play a lengthy description.
• (EAD-3) Support resuming playback of video and main audio tracks when the description is finished.

Accept this section?

Summary

Details

Refer to 2.4 Clear audio.

A relatively recent development in television accessibility is the concept of clear audio, which takes advantage of the increased adoption of multichannel audio. This is primarily aimed at audiences who are hard of hearing, and consists of isolating the audio channel containing the spoken dialog and important non dialog audio that can then be amplified, or otherwise modified, while the other channels (containing music or ambient sounds) are attenuated.

Using the isolated audio track may make it possible to apply more sophisticated audio processing such as pre-emphasis filters, pitch shifting and so on to tailor the audio to the users needs, since hearing loss is typically frequency dependant, and the user may have reasonable hearing in some bands, yet none at all in others.

Requirements

Systems supporting clear audio must:

• (CA-1) Support speech as a separate audio track from other sounds.
• (CA-2) Support the synchronisation of multitrack audio either within the same file or from separate files - preferably both.
• (CA-3) Support separate volume control of the different audio tracks.
• (CA-4) Potentially support pre-emphasis filers, pitch shifting, and other audio processing algorithms.

Accept this section?

Summary

Details

Refer to 2.5 Content Navigation by Content Structure.

Most people are familiar with fast forward and rewind in media content. However, fast forward and rewind, because they progress through content based only on time, are ineffective particularly when the content is being used for other than entertainment purposes. People with disabilities are also particularly disadvantaged if forced to rely solely on time-based forward and rewind to study content.

Fortunately, most content is structured, and appropriate markup can expose this structure to forward and rewind controls:

• Books generally have chapters and perhaps subsections within those chapters. They also have structures such as page numbers, side-bars, tables, footnotes, tables of contents, glossaries, etc.
• Short music selections tend to have versus and repeating choruses.
• Larger musical works have movements which are further dividable by component parts such as "Exposition, Development, and Recapitulation;" or "Theme and Variations."
• Operas, theatrical plays, and movies have acts and scenes within those acts.
• Television programs generally have clear divisions, e.g. newscasts have individual stories usually wrapped within a larger structure called "News, Weather, and Sports."
• A lecturer may first lay out the issue, then consider a series of approaches or illustrative examples, and finally the lecturer's conclusion.

Support for effective structural navigation will require an additional control not typically available on current media players. This realtime control will allow the user to adjust the level of granularity applied to "next" and "previous" controls.

Two Examples of Granularity Levels

1. In a news broadcast, the most global level (analogous to <h1>) might be "News, Weather, and Sports." The second level (analogous to <h2>) would identify each individual news (or sports) story. With the granularity control set to level 1, "next" and "previous" would cycle among "News, Weather, and Sports." Set at level 2, it would cycle among individual news (or sports) stories.

2. In a bilingual "Audiobook Plus Text" production of Dante Alighieri's "La Divina Commedia," the user would choose whether to listen to the original medieval Italian or its modern language translation--possibly toggling between them. Meanwhile, both the original and translated texts might appear on screen, with both the original and translated text highlighted, line by line, in sync with the audio narration.

• The most global (<h1>) level would be each individual "book," "Inferno," "Purgatorio," and "Paradiso."
• The second (<h2>) level would be each individual "Canto."
• The third (<h3>) level would be each individual "Verso."
• The fourth (<h4>) level would be each individual line of poetry.

With granularity set at level 1, "Next" and "Previous" would cycle among the three books of "The Divine Comedy." Set at level 2, they would cycle among its "Cantos," at level 3 among its "Versos," and at level 4 among the individual lines of poetry text.

Note that, just as printed books may have footnotes, sidebars, and other ancillary content structures, media productions may also contain ancillary content. Newscasts will have commercials. Audio productions of "The Divine Comedy" may well include reproductions of famous frescoes or paintings interspersed throughout the text, though these are not properly part of the text/content.

Just as the structures introduced particularly by nonfictional titles make books more usable, media is more usable when its inherent structure is exposed by markup. And, markup-based access to structure is critical for persons with disabilities who possess less ability to infer structure from purely presentational queues.

Structural navigation has proven highly effective internationally in various programs of electronic book publication for persons with print disabilities. Nowadays, these programs are based on the ANSI/NISO Z39.86 specifications. Z39.86 structural navigation is also supported by e-publishing industry specifications.

The user can navigate along the timebase using a continuous scale, and by relative time units within rendered audio and animations (including video and animated images) that last three or more seconds at their default playback rate. (UAAG 2.0 4.9.6?)

The user can navigate by semantic structure within the time-based media, such as by chapters or scenes, if present in the media (UAAG 2.0 4.9.7).

Requirements

Systems supporting content navigation must:

• (CN-1) Generally, provide accessible keyboard controls for navigating a media resource in lieu of clicking on the transport bar need to be available, e.g. 5sec forward/back, 30sec forward/back, beginning, end.
• (CN-2) Provide a means to structure a media resource by semantic content structure, e.g. through adding a track to the video that contains navigation markers (in table-of-content style). Such a track can be provided as part of the media resource or externally and synchronised with the media resource.
• (CN-3) The navigation track should provide for hierarchical structures with titles for the sections.
• (CN-4) Support both global navigation by the larger structural elements of a media work, and also the most localized atomic structures of that work, even though authors may not have marked-up all levels of navigational granularity.
• (CN-5) Be possible through third-party provided navigational markup files.
• (CN-6) Keep all content representations in sync, so that moving to any particular structural element in media content also moves to the corresponding point in all provided alternate media representations (captions, described video, transcripts, etc) associated with that work.
• (CN-7) Support direct access to any structural element, possibly through URIs.
• (CN-8) Support pausing primary content traversal to provide access to such ancillary content in line.
• (CN-9) Support skipping of ancillary content in order to not interrupt content flow.
• (CN-10) Support direct access to each ancillary content item, including with "next" and "previous" controls, apart from accessing the primary content of the title.

Accept this section?

Summary

Details

Refer to 2.6 Captioning.

For people who are deaf or hard of hearing, captioning is the main alternative representation of audio. Captions are always written in the same language as the main audio track. They not only render the audio as text on the screen, they also indicate important non-speech information, such as sound effects, music and laughter. Captions are either closed or open. Closed captions are transmitted as data along with the video but are not visible until the user elects to turn them on, usually by invoking an on-screen control or menu selection. Open captions are always visible; they have been merged with the video track and cannot be turned off.

Ideally captions should be a verbatim representation of the audio; however, captions are sometimes edited for various reasons-- for example, for reading speed or for language level. In general, consumers of captions have expressed that the text should represent exactly what is in the audio track. If edited captions are provided, then they should be clearly marked as such, and the full verbatim version should also be available as an option.

The timing of caption text can coincide with the mouth movement of the speaker (where visible), but it is not strictly necessary. For timing purposes, captions may sometimes precede or extend slightly after the audio they represent. Captioning should also use adequate means to distinguish between speakers as turn-taking occurs during conversation; this is commonly done by positioning the text near the speaker, although in some countries color is used to indicate a change in speaker.

Captions are useful to a wide array of users in addition to their originally intended audiences. Gyms, bars and restaurants regularly employ captions as a way for patrons to watch television while in those establishments. People learning to read or learning English as a second language also benefit from captions: research has shown that captions help reinforce vocabulary and language. Captions can also provide a powerful search capability, allowing users to search the caption text to locate a specific video or an exact point in a video.

Requirements

Formats for captions, subtitles or foreign-language subtitles must:

• (CC-1) Render text in a time-synchronized manner, using the audio track as the timebase master.
• (CC-2) Allow the author to specify erasures, when no text is displayed on the screen.
• (CC-3) Allow the author to assign timestamps so that one caption/subtitle follows another, with no perceivable gap in between.
• (CC-4) Be available in a text encoding.
• (CC-5) Support positioning in all parts of the screen.
• (CC-6) Support the display of multiple regions of text simultaneously.
• (CC-7) Display multiple rows of text when rendered as text in a right-to-left- or left-to-right language.
• (CC-8) Allow the author to specify line breaks.
• (CC-9) Permit a range of font faces and sizes.
• (CC-10) Render a background in a range of colors, supporting a full range of opacities.
• (CC-11) Render text in a range of colors.
• (CC-12) Render text with an outline or drop shadow.
• (CC-13) Allow the background to be removed or to remain on screen when no text is displayed.
• (CC-14) Allow the use of mixed display styles-- e.g., mixing paint-on captions with pop-on captions-- within a single caption or in the caption stream as a whole.
• (CC-15) Support positioning such that the lowest line of captions appears 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.
• (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.
• (CC-17) Represent content of different natural languages, where the content of distinct languages may be segregated into separate documents or integrated into a single document.
• (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).
• (CC-19) Present the full range of typographical glyphs, layout and punctuation marks normally associated with the natural language's print writing system.
• (CC-20) Permit in-line mark-up for foreign words or phrases.
• (CC-21) Permit the distinction between different speakers.

Further, systems that support captions must:

• (CC-22) Support captions provided inside media resources as tracks, or in external files.
• (CC-23) Ascertain that captions are displayed in sync with the media resource.
• (CC-24) Support user activation/deactivation of caption tracks.
• (CC-25) Support edited and full verbatim captions.
• (CC-26) Support multiple tracks of captions in different languages.

Accept this section?

Summary

Details

Refer to 2.7 Extended Captioning.

Extended captioning adds additional metadata to captions so that a richer, more hypertext-like experience is possible – for example, adding glossary definitions for acronyms and other intialisms, foreign terms (for example Latin), jargon or other difficult language. This may be age-graded, so that multiple caption tracks are supplied, or the glossary function may be added dynamically. Glossary information can be added in the normal time allotted for the caption (e.g. as a callout or other overlay), or it might take the form of a hyperlink that pauses the main content and allows access to more complete explanatory material.

Extended captioning can be useful for those with restricted reading skills. In addition, captioning can be provided for the audio-description track. This may prove helpful for comprehension, especially when extended descriptions are being used.

Requirements

Systems that support extended captions must:

• (ECC-1) Support metadata markup for (sections of) caption text.
• (ECC-2) Support hyperlinks and other activation mechanisms for supplementary data for (sections of) caption text.
• (ECC-3) Support alternative extended caption tracks for different purposes.
• (ECC-4) Support captions that may be longer than the space to the next caption and thus provide overlapping caption cues - in this case, a feature should be provided to decide if overlap is ok or should be cut or the media resource be paused while the caption is displayed.

Accept this section?

Summary

Details

Refer to 2.8 Sign Translation.

Sign language shares the same concept as captioning: it presents both speech and non-speech information in an alternative format. Note that due to the wide regional variation in signing systems (e.g., American Sign Language vs British Sign Language), sign translation may not be appropriate for content with a global audience unless localized variants can be made available.

From a technology point of view signing can be open, mixed with the video and offered as an entirely alternate stream or closed (using some form of picture-in-picture or alpha blending technology). It is possible to use quite low bit rates for much of the signing track, but it is important that facial, arm, hand and other body gestures be delivered at sufficient resolution to support legibility. Animated avatars may not currently be sufficient as a substitute for human signers, although research continues in this area and it may become practical at some point in the future.

Requirements

Systems supporting sign language must:

• (SL-1) Support sign language video either as a track as part of a media resource or as an external file.
• (SL-2) Support the synchronised playback of the sign language video with the media resource.
• (SL-3) Support the display of sign language video either as picture-in-picture or alpha-blended overlay, as parallel video, or as the main video with the original video as picture-in-picture or alpha-blended overlay.
• (SL-4) Support multiple sign language tracks in several sign languages.
• (SL-5) Support the interactive activation/deactivation of a sign language track by the user.

Accept this section?

Summary

Details

Refer to 2.9 Transcripts.

While synchronized captions are preferable for people with hearing impairments, for some users they are not viable – those who are deaf-blind, for example, or those with cognitive or reading impairments that make it impossible to follow synchronized captions. And even with ordinary captions, it is possible to miss some information as the captions and the video require two separate loci of attention. Providing a full transcript is a good option in addition to, but not as a replacement for, timed captioning. A transcript can either be presented simultaneously with the media material, which can assist slower readers or those who need more time to reference context, but it should also be made available independently of the media.

A full text transcript should include information that would be in both the caption and audio description, so that it is a complete representation of the material, as well as containing any interactive options.

Requirements

Systems supporting transcript must:

• (T-1) Support the provisioning of a full text transcript for the media asset in a separate but linked resource, where the linkage is programatically accessible to AT.
• (T-2) Support the provisioning of a full text transcript with the media resource, e.g. in a scrolling area next to the video or underneath the video, which is also AT accessible.

Accept this section?

Summary

Details

Refer to 3.1 Keyboard Access to interactive controls / menus.

Ideally, the user agent would have a rich set of native controls for media operation. This would ensure that the controls are discoverable by the user and assistive technology. These controls include but are not limited to: play, pause, stop, jump to beginning, jump to end, scale player size (up to full screen), adjust volume, mute, captions on/off, descriptions on/off, selection of audio language, selection of caption language, selection of audio description language, location of captions, size of captions, video contrast/brightness, playback rate, content navigation on same level (next/prev) and between levels (up/down) etc.

The author would be able to choose any/all of the controls, skin them and position them. The user would have the ability to override all author settings. If the author chose to create a new interface using scripting, that interface MUST map to the native controls in the user agent, so the user can ignore author controls and use accessible native controls.

Requirements

Systems supporting keyboard accessibility must:

• (KA-1) Support operation of all functionality via the keyboard using sequential or direct keyboard commands that do not require specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints (e.g., free hand drawing). This does not forbid and should not discourage providing mouse input or other input methods in addition to keyboard operation. (UAAG 2.0 4.1.1)

Accept this section?

Summary

Details

Refer to 3.2 Granularity Level Control for Structural Navigation.

As explained in Section "Content Navigation" above, a realtime control mechanism is required for adjusting the granularity of what specific structural navigation point "next" and "previous" controls will access.

Requirements

• (CNS-1) All identified structures, including ancillary content as defined in "Content Navigation" above, must be accessible with the use of "next" and "previous," as refined by the granularity control.
• (CNS-2) Ancillary structures must provide the possibility to be skipped, played in line, or accessed directly apart from primary content.
• (CNS-3) This control must be input device agnostic.
• (CNS-4) Producers and authors may optionally provide additional access options to identified structures, such as direct access to any node in a Table of Contents.

Accept this section?

Summary

Details

Refer to 3.3 Time Scale Modification.

While all devices may not support the capability, a standard control API must support the ability to speed up or slow down content presentation without altering audio pitch.

Requirements

The user can adjust the playback rate of prerecorded time-based media content, such that all of the following are true (UAAG 2.0 4.9.5):

• (TSM-1) The user can adjust the playback rate of the time-based media tracks to between 50% and 250% of real time.
• (TSM-2) Speech whose playback rate has been adjusted by the user maintains pitch in order to limit degradation of the speech quality.
• (TSM-3) Audio and video tracks remain synchronized across this required range of playback rates.
• (TSM-4) The user agent provides a function that resets the playback rate to normal (100%).
• (TSM-5)The user can stop, pause, and resume rendered audio and animation content (including video and animated images) that last three or more seconds at their default playback rate. (UAAG 2.0 4.9.6)

Accept this section?

Summary

Details

Refer to 3.4 Production practice and resulting requirements.

One of the biggest problems to date has been the lack of a universal system for media access. In response to user requirements various countries and groups have defined systems to provide accessibility, especially captioning for television. However these systems are typically not compatible. In some cases the formats can be inter-converted, but some formats – for example DVD sub-pictures – are image based and are difficult to convert to text.

Caption formats are often geared towards delivery of the media, for example as part of a television broadcast. They are not well suited to the production phases of media creation. Media creators have developed their own internal formats which are more amenable to the editing phase, but to date there has been no common format that allows interchange of this data.

Any media based solution should attempt to reduce as far as possible layers of translation between production and delivery.

In general captioners use a proprietary workstation to prepare caption files; these can often export to various standard broadcast ingest formats, but in general files are not inter-convertible. Most video editing suites are not set up to preserve captioning, and so this has typically to be added after the final edit is decided on; furthermore since this work is often outsourced, the copyright holder may not hold the final editable version of the captions. Thus when programming is later re-purposed, e.g. a shorter edit is made, or a ‘directors cut’ produced, the captioning may have to be redone in its entirety. Similarly, and particularly for news footage, parts of the media may go to web before the final TV edit is made, and thus the captions that are produced for the final TV edit are not available for the web version.

It is important when purchasing or commissioning media, that captioning and audio description is taken into account and made equal priority in terms of ownership, rights of use, etc., as the video and audio itself.

Requirements

Systems supporting accessibility needs for media must:

• (PP-1) Support existing production practice for alternative content resources, in particular allow for the association of separate alternative content resources to media resources.
• (PP-2) Support the association of authoring and rights metadata with alternative content resources.
• (PP-3) Support the simple replacement of alternative content resources even after publishing.

Accept this section?

Summary

(1 response didn't contain an answer to this question)

Details

Refer to 3.5 Discovery and activation/deactivation of available alternative content by the user.

As described above, individuals need a variety of media (alternative content) in order to perceive and understand the content. The author or some web mechanism provides the alternative content. This alternative content may be part of the original content, embeded within the media container as 'fallback content', or linked from the original content. The user is faced with discovering the availability of alternative content.

Requirements

The user agent can facilitate the discovery of alternative content by following the criteria:

• (DAC-1) The user has the ability to have indicators rendered along with rendered elements that have alternative content (e.g. visual icons rendered in proximity of content which has short text alternatives, long descriptions, or captions). In cases where the alternative content has different dimensions than the original content, the user has the option to specify how the layout/reflow of the document should be handled. (UAAG 2.0 3.1.1).
• (DAC-2) The user has a global option to specify which types of alternative content by default and, in cases where the alternative content has different dimensions than the original content, how the layout/reflow of the document should be handled. (UAAG 2.0 3.1.2).
• (DAC-3) The user can browse the alternatives, switch between them.
• (DAC-4) Synchronized alternatives for time-based media (e.g., captions, audio descriptions, sign language) can be rendered at the same time as their associated audio tracks and visual tracks (UAAG 2.0 3.1.3).
• (DAC-5) Non-synchronized alternatives (e.g., short text alternatives, long descriptions) can be rendered as replacements for the original rendered content (UAAG 2.0 3.1.3).
• (DAC-6) Provide the user with the global option to configure a cascade of types of alternatives to render by default, in case a preferred alternative content type is unavailable (UAAG 2.0 3.1.4).
• (DAC-7) During time-based media playback, the user can determine which tracks are available and select or deselect tracks. These selections may override global default settings for captions, audio descriptions, etc. (UAAG 2.0 4.9.8)
• (DAC-8) Provide the user with the option to load time-based media content such that the first frame is displayed (if video), but the content is not played until explicit user request. (UAAG 2.0 4.9.2)

Accept this section?

Summary

Details

Refer to 3.6 Requirements on making properties available to the accessibility interface .

Often forgotten in media systems, especially with the newer forms of packaging such as DVD menus and on screen program guides, is the fact that the user needs to actually get to the content, and turn on any accessibility options they require. For players running on platforms that support an accessibility API any media controls need to be connected to that API.

On self-contained products that do not support assistive technology, any menus in the content need to provide information in alternative formats (e.g., talking menus). Products with a separate remote control, or that are self-contained boxes, should ensure the physical design does not block access, and should make accessibility controls, such as the closed-caption toggle, as prominent as the volume or channel controls.

Requirements

• (API-1) Support to expose the alternative content tracks for a media resource to the user, i.e. to the browser.
• (API-2) Since authors will need access to the alternative content tracks, too, the structure needs to be exposed to authors, too, which requires a dynamic interface.
• (API-3) Accessibility APIs need to gain access to alternative content tracks, too, no matter whether those content tracks come from within a resource or are combined through markup on the page.
• (API-4) External control devices, such as remote controls, need to be enabled to access alternative content tracks, too.

Accept this section?

Summary

Details

Refer to 3.7 Requirements on the use of the viewport.

The view port in particular of the video plays a particularly important role wrt alternative content technologies. Mostly it provides a bounding box for many of the visually represented alternative content technologies (e.g. captions, hierarchical navigation points, sign language), although some alternative content does not rely on that (e.g. audio descriptions, full transcripts).

One key principle to remember when designing player ‘skins’ is that the lower-third of the video may be needed for caption text (either in the video or as closed captions). Caption consumers rely on being able to make fast eye movements between the captions and the video content, if the captions are in a non-standard place, this may slow them down and cause them to miss information. The use of this area for other controls such as transport controls, whilst appealing aesthetically, may lead to accessibility issues.

Requirements

• (VP-1) If alternative content has a different height or width to the media content, then the user agent will reflow the viewport. (UAAG 2.0 3.1.4).
• (VP-2) The user can globally set the following characteristics of visually rendered text content, overriding any specified by the author or user agent defaults (UAAG 2.0 3.6.1). (Note: this should include captions):
  • (a) text scale (i.e., the general size of text) ,
  • (b) font family, and
  • (c) text color (i.e., foreground and background).
• (VP-3) Provide the user with the ability to adjust the size of the time-based media up to the full height or width of the containing viewport, with the ability to preserve aspect ratio and to adjust the size of the playback viewport to avoid cropping, within the scaling limitations imposed by the media itself. (UAAG 2.0 4.9.9)
• (VP-4) Provide the user with the ability to control the contrast and brightness of the content within the playback viewport. (UAAG 2.0 4.9.11)
• (VP-5) Captions occupy traditionally the lower-third of the video - the use of this area for other controls or content needs to be avoided.

Accept this section?

Summary

(1 response didn't contain an answer to this question)

Details

Refer to 3.8 Requirements on the parallel use of alternate content on potentially multiple devices in parallel.

Multiple user devices must be directly addressable. It must be assumed that many users will have multiple video displays and/or multiple audio output devices attached to an individual computer, or addressable via LAN. It must be possible to configure certain types of media for presentation on specific devices, and these configuration settings must be readily overwritable on a case by case basis by users.

Requirements

Systems supporting multiple devices for accessibility must:

• (MD-1) Support an platform accessibility architecture relevant to the operating environment. (UAAG 2.0 2.1.1)
• (MD-2) Ensure accessibility of all user interface components including the user interface, rendered content, and alternative content, make available the name, role, state, value, and description via a platform accessibility architecture. (UAAG 2.0 2.1.2)
• (MD-3) If a feature is not supported by the accessibility architecture(s), provide an equivalent feature that does support the accessibility architecture(s). Document the equivalent feature in the conformance claim. (UAAG 2.0 2.1.3)
• (MD-4) If the user agent implements one or more DOMs, they must be made programmatically available to assistive technologies. (UAAG 2.0 2.1.4) This assumes the video element will write to the DOM.
• (MD-5) If the user can modify the state or value of a piece of content through the user interface (e.g., by checking a box or editing a text area), the same degree of write access is available programmatically (UAAG 2.0 2.1.5).
• (MD-6) If any of the following properties are supported by the accessibility platform architecture, make the properties available to the accessibility platform architecture (UAAG 2.0 2.1.6):
  • (a) the bounding dimensions and coordinates of rendered graphical objects
  • (b) font family of text
  • (c) font size of text
  • (d) foreground color of text
  • (e) background color of text.
  • (f) change state/value notifications
• (MD-7) Ensure that programmatic exchanges between APIs proceed at a rate such that users do not perceive a delay. (UAAG 2.0 2.1.7).

Accept this section?

Summary

(1 response didn't contain an answer to this question)

Details