Sign Language (Prerecorded)

[ecureuill]

1.2.6

Sign language interpretation is provided for all prerecorded audio content in synchronized media.

Tasks

List the tasks required to accomplish the requirement (not exhaustive)

• [x] SYSTEM MUST include SELI's videos contents with sign language for all videos that student may consume.

• IF TEACHER uploads a video content, i.e. video-only checkbox not checked

  • [x] SYSTEM MUST provide a checkbox to TEACHER marks if the video has sign-language embedded. G54

• IF TEACHER uploads a video content without embedded sign-language, i.e. embedded sign-language checkbox not checked

  • [x] SYSTEM MUST provide an option to TEACHER uploads a video of the sign language interpreter. G81

• SYSTEM MUST render teacher's video content with it sign-language, if teacher configure one.

Resources

For G81

• HTML5 multi-track audio or video
• Able Player 2.01

  Able Player is a fully accessible cross-browser HTML5 media player.

Intent

The intent of this Success Criterion is to enable people who are deaf or hard of hearing and who are fluent in a sign language to understand the content of the audio track of synchronized media presentations.

Examples

1. Example 1. A corporation is making an important announcement to all of its employees. The meeting will be held in the main headquarters and streamed to the Web. A sign language interpreter is provided at the meeting location. The live video includes a full view of the sign language interpreter as well as the person presenting.
2. Example 2. The same announcement described in example 1 is also Webcast to remote employees. Since there is only one display available for this, the sign language interpreter is shown in the corner of the display.
3. Example 3. A university is providing an on-line version of a particular lecture by creating a synchronized media presentation of the professor delivering the lecture. The presentation includes video of the professor speaking and demonstrating a science experiment. A sign language interpretation of the lecture is created and presented on the Web with the synchronized media version.

Sufficient Techniques

Sufficient techniques are reliable ways to meet the success criteria.

• From an author's perspective: If you use the sufficient techniques for a given criterion correctly and it is accessibility-supported for your users, you can be confident that you met the success criterion.
• From an evaluator's perspective: If web content implements the sufficient techniques for a given criterion correctly and it is accessibility-supported for the content's users, it conforms to that success criterion. (The converse is not true; if content does not implement these sufficient techniques, it does not necessarily fail the success criteria, as explained in Testing Techniques below.) There may be other ways to meet success criteria besides the sufficient techniques in W3C's Techniques for WCAG document, as Other Techniques below. (See also Techniques are Informative above.)

• G54
• G81

G54: Including a sign language interpreter in the video stream

One universally compatible way of doing this is to simply embed a video of the sign language interpreter in the video stream. This has the disadvantage of providing a lower resolution image that cannot be easily enlarged without enlarging the entire image.

NOTE If the video stream is too small, the sign language interpreter will be indiscernible. When creating a video stream that includes a video of a sign language interpreter, make sure there is a mechanism to play the video stream full screen in the accessibility-supported content technology. Otherwise, be sure the interpreter portion of the video is adjustable to the size it would be had the entire video stream been full screen.

Since sign language is not usually a signed version of the printed language, the author has to decide which sign language to include. Usually the sign language of the primary audience would be used. If intended for multiple audiences, multiple sign languages may be used. Refer to advisory techniques for multiple sign languages.

Example

1. A television station provides a sign language interpreter in the corner of or beside its on-line news video.

Test Procedure

1. Have someone watch the program who can hear and is familiar with the sign language being used.
2. Check to see if there is a sign language interpreter on screen.
3. Check to see that dialogue and important sounds are being conveyed by the interpreter visible on screen.

Expected Results

Check # 2 and # 3 are true

G81: Providing a synchronized video of the sign language interpreter that can be displayed in a different viewport or overlaid on the image by the player

This technique accomplishes this by providing the sign language interpretation as a separate video stream that is synchronized with the original video stream. Depending on the player, this secondary video stream can be overlaid on top of the original video or displayed in a separate window. It may also be possible to enlarge the sign language interpreter separately from the original video to make it easier to read the hand, body and facial movements of the signer.

Example A university provides a synchronized sign language interpreter video stream that can be displayed, at the viewer's option, along with any of their education programs.

Test Procedure

1. Enable the display of the sign-language window in the player.
2. Have someone watch the program who can hear and is familiar with the sign language being used.
3. Check to see if there is a sign language interpreter on screen or in a separate window.
4. Check to see that dialogue and important sounds are being conveyed by the interpreter and are synchronized with the audio.

Expected Results

Check #3 and #4 are true

:notebook_with_decorative_cover: References

• How to Meet WCAG (Quick Reference)
• Understanding Techniques for WCAG Success Criteria

GLOSSARY

• SELI's content: all contents not created by users (e.g. seli "about" section text)

:warning: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119/8174.

1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification.
2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification.
3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.
5. MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.)

[github-actions[bot]]

This Feature is ready to be implemented.

[github-actions[bot]]

Functional Test failed! Please, review your solution.

[github-actions[bot]]

This Feature is ready to be implemented.