This Wiki page is edited by participants of the HTML Accessibility Task Force. It does not necessarily represent consensus and it may have incorrect information or information that is not supported by other Task Force participants, WAI, or W3C. It may also have some very useful information.
From HTML accessibility task force Wiki
What kinds of accessibility needs might exist for multimedia?
- User is unable to see; alternatives to visual are needed
- User needs higher contrast than usual
- Use needs lower-contrast than usual
- User is unable to hear, needs alternatives to audio
- Use can hear, but needs the 'key content' more audible ("high contrast")
- User needs content without repetitive stimuli (flashing or audio)
- User can follow multimedia, but needs it presented more slowly than normal
- User needs to be able to user keyboard controls for audio and video
What means of satisfying these needs exist?
- High/Low Video Contrast:
- Tends to be solved by the computer hardware or the operating system since it is a system-wide requirement
- High/Low Audio Contrast:
- Should be solved by the computer sound system through specific filters since it is a system-wide requirement
- Lack of repetitive stimuli:
- Tends to be a requirement towards Web page authors - should now also be required for audio-visual content authors
- alternatively, sections with repetitive stimuli could be market and be skippable
- Speed reduction:
- Tends to be used by ability to repeat sections
- An ability to reduce playback speed to a certain degree is possible too
- Keyboard controls:
- Browsers need to implement keyboard controls on default video and audio controls - might need to be added to spec.
- non-synchronized textual description of video content, read out by screen reader or through braille, e.g. linked transcript using aria:describedBy or in-page
- non-timed in-element textual summary of video content, e.g. @summary attribute
- synchronized audio description
- synchronized textual audio description read about by a screen reader or through braille
- synchronized extended audio description, which requires pausing of the main video to finish reading out
- synchronized extended textual audio description, which requires pausing of the main video to finish reading out
- non-synchronized textual transcript of audio content, e.g. linked transcript using aria:describedBy or in-page
- non-timed in-element textual summary of audio content, e.g. @summary
- synchronized captions of the textual transcript (in particular where there is also visual content)
- sign language video (in an appropriate dialect, ideally)
Accommodation Provision and detection
Where might the accommodation be?
- Separate file
- associated by the author/page,
- associated by the user
- If in-file, how do we select the appropriate file, if there is a choice?
- Media queries have been suggested and are already allowed on the source element
- If in-file, how do we configure the file, if it needs it?
- That is the job of the media engine (to be sensitive to the same user needs as the media queries are)
- How does the page/script become aware of what in-file accommodations might be possible?
For in-file media, do we need to standardize or recommend any formats?
- 3GPP Timed Text for text in MP4-family files?
- Kate for text in Ogg-family files?
For associated files for captions/subtitles, do we need to standardize or recommend any formats?
- SRT as an associated file format?
- Should we document SRT?
- DFXP as an associated file format?
GFreed: Why go through the trouble of documenting and approving SRT as a text-display standard? The W3C already has one-- TTML/DFXP. If members think TTML is too complex to use as a default format, can we not recommend a subset?
For associated files for audio descriptions, do we need to standardize or recommend any formats?
- Text for use by a speech synthesizer to make audio descriptions?
- Could simply be SRT being used as textual audio description
- Can we associate external audio files?
- Can we associate external sign language video files?
Resources, tips, techniques etc.
What resources, data-flows, tools, techniques and tips can we give to an author wanting to make accessible pages?