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.

Media Sub-Group

From HTML accessibility task force Wiki
Jump to: navigation, search


Introduction

This is the home of the HTML5 Accessible Media (aka HAM) sub-group, discussing accessibility of the video and audio elements in HTML5. (Media Accessibility was not chosen as a name, so as to avoid confusion with the Media Annotation Working Group).

This group is currently active and being led by Janina Sajka and Mark Sadecki.

Resources

Meetings

The Media Sub-Group will meet every Monday at 16:00 Boston Time (22:00 UTC) until work is concluded.

Next meeting: Monday, December 8, 2014 at 16:00 Boston Time (use as reference)

Meeting information is as follows:

  • IRC: server: irc.w3.org, channel: #html-a11y-media.
  • Zakim Code: 2119# (a11y#)

Next Agenda

for December 8th, 2014

Meeting: HTML Accessibility Task Force Media Sub-Group
Chair: Janina Sajka
agenda+ Identify Scribe
agenda+ Edits to Media Accessibility User Requirements
agenda+ Media Accessibility User Requirements Comment Responses

Current Work Items

Resources

First pass at analyzing Use Cases from Round 1

Meeting Minutes

Wiki

This is the wiki for the HTML Accessibility Task Force Media Sub-Group.

The W3C HTML working group's Multimedia Accessibility Wiki page provides a detailed history of the issue from 2007 to date. It includes:

Development of accessibility requirements.

Mailing List

In order to provide the best opportunity for feedback, and to avoid excessive fragmentation of the mailing lists, we will use the main HTML Accessibility mailing list for the time being. If traffic gets heavy and either we overwhelm other members, or we feel drowned in a sea of emails and we can't find the media-related discussions, we'll create a new list. It will help if people put (Media) in the headers of the media-related emails.

Tracker, Issues and Actions

Bugs

The keywords that apply here are:

  • "media" used to identify multimedia-related bugs;
  • "a11y" to identify accessibility-related bugs;
  • "a11ytf" to identify bugs that have been 'taken on' and supported by the task force.

You can therefore ask for a list of Bugzilla entries for media tracked by the task force (keywords "a11ytf, media").

Some possible related bugs are as follows; they are not supported by the task force unless the keyword a11ytf is on them.

Wiki-tracked discussions

We have an experimental Multimedia Q&A ongoing, with discussions in email and accumulated questions.

User requirements are being worked out in Media Accessibility User Requirements.

An assessment as to what technologies need to be adapted for the requirements to be met is at Media Accessibility Checklist.

Best Practices

We hope to assemble a best practices document, in which we pull together all the information. This will also inspire the changes we need to the specifications, we hope.

Impact on Specifications

In here, we track the proposed changes to various specifications.

CSS Media Queries for Source Selection

It has been proposed and generally accepted that since Media Queries can be used to select a source element, if we define media queries related to accessibility needs (e.g. "I need captions if they are available") then the source selection algorithm will help find a suitable (e.g. captioned) source. This would be a revision to the CSS Media Queries specification, adding new keywords. It's possible that other HTML5 elements could also benefit from such expression. The media queries would be sensitive to the browser's awareness of the user's accessibility desires, though the capture and expression of those desires is out of the scope of the W3C.

HTML5 Media Engine sensitivity to Accessibility needs

Similarly, a source, once selected, may need to be configured to respond to the user's accessibility desires. Again, the way this happens is out of scope for the W3C, however the HTML5 specification needs to say that it should happen. (E.g. if the closed caption track is optional, and the user indicates a desire for closed captions, enable that track automatically).

JavaScript API for Multitrack Media Resources

This draft proposal introduces a JavaScript API for extracting basic information about the tracks contained inside a media resource (audio or video), which may include audio descriptions, sign language video, closed captions or subtitles.

Declarative Markup for Associated External Text Alternatives

This draft proposal introduces declarative markup into the audio and video elements of HTML5 to link to external resources that provide text alternatives for different roles, such as captions, subtitles and textual audio descriptions. This includes styling defaults and a resource selection algorithm for when there are alternative resources available.

Experiments, history, background and supporting material

There was an informal get-together preceding TPAC 2009, at Stanford, and minutes are available.

There was also a get-together at TPAC.

External Resources

A useful compendium of specifications, sites providing data or services related to media accessibility, and so on.