Accessibility/Captioning Work Plan: Difference between revisions
Jump to navigation
Jump to search
(Merge comments from IRC vol 1) |
|||
| Line 5: | Line 5: | ||
= Work plan = | = Work plan = | ||
# Determine which captioning format should be supported in Mozilla. This needs to take into account x, y and z. DFXP? CMML? (What are the known pros and cons) | # Determine which captioning format should be supported in Mozilla for the natively-supported Ogg video. This needs to take into account x, y and z. DFXP? CMML? (What are the known pros and cons) | ||
# Determine which subset of that format is the most crucial. This can save the Mozilla developers a good deal of work, because captioning formats are complex. Some of the complexity is necessary and some is not necessary for Mozilla suppoort | # Determine which subset of that format is the most crucial. This can save the Mozilla developers a good deal of work, because captioning formats are complex. Some of the complexity is necessary and some is not necessary for Mozilla suppoort | ||
# Work with HTML 5, web browser development and captioning communities to ensure that the solution will be accepted. We don't want different solutions in each browser. That would either mean one browser would need to redo their work, or that caption developers would have to deal with incompatible solutions in different browsers. | # Work with HTML 5, web browser development and captioning communities to ensure that the solution will be accepted. We don't want different solutions in each browser. That would either mean one browser would need to redo their work, or that caption developers would have to deal with incompatible solutions in different browsers. | ||
# | # Explore the need to support the following features and ensure support when found necessary: | ||
##social caption creation (This poses very different requirements than the idea of making video files intrinsically accessible. [[User:Hsivonen|Hsivonen]] 09:06, 4 August 2008 (UTC)) | |||
##metadata indicating changes in captioning language for search and Braille. (Google seems to be doing better by ignoring author-entered language metadata. Is rendering foreign words into Braille strong enough an use case to justify the complexity of supporting this and authoring with this data. [[User:Hsivonen|Hsivonen]] 09:06, 4 August 2008 (UTC)) | |||
##semantics and style, etc. (This seems like a pretty big departure from baseline established by TV captioning. [[User:Hsivonen|Hsivonen]] 09:06, 4 August 2008 (UTC)) | |||
# Ensure captioning solution is compatible with current authoring and if possible, video conversion tools, so that current and future content can easily use the solution | # Ensure captioning solution is compatible with current authoring and if possible, video conversion tools, so that current and future content can easily use the solution | ||
# Determine what can be done about supporting captioning when an external back end (gstreamer, QuickTime, DirectShow) is in use. (MP4 containers are the most likely external back end case, so 3GPP Timed Text is a potential format candidate in that case.) | |||
# Build test cases -- we need x testcases with y features | # Build test cases -- we need x testcases with y features | ||
# Build documentation for developers and content creators | # Build documentation for developers and content creators | ||
Revision as of 09:06, 4 August 2008
To do:
- Separate into phase 1 and phase 2. I suggest that the work plan say in bold for each item, what the deliverable is, e.g. "Deliverable: test cases"
- Add technology specifics -- any specifics we need
Work plan
- Determine which captioning format should be supported in Mozilla for the natively-supported Ogg video. This needs to take into account x, y and z. DFXP? CMML? (What are the known pros and cons)
- Determine which subset of that format is the most crucial. This can save the Mozilla developers a good deal of work, because captioning formats are complex. Some of the complexity is necessary and some is not necessary for Mozilla suppoort
- Work with HTML 5, web browser development and captioning communities to ensure that the solution will be accepted. We don't want different solutions in each browser. That would either mean one browser would need to redo their work, or that caption developers would have to deal with incompatible solutions in different browsers.
- Explore the need to support the following features and ensure support when found necessary:
- social caption creation (This poses very different requirements than the idea of making video files intrinsically accessible. Hsivonen 09:06, 4 August 2008 (UTC))
- metadata indicating changes in captioning language for search and Braille. (Google seems to be doing better by ignoring author-entered language metadata. Is rendering foreign words into Braille strong enough an use case to justify the complexity of supporting this and authoring with this data. Hsivonen 09:06, 4 August 2008 (UTC))
- semantics and style, etc. (This seems like a pretty big departure from baseline established by TV captioning. Hsivonen 09:06, 4 August 2008 (UTC))
- Ensure captioning solution is compatible with current authoring and if possible, video conversion tools, so that current and future content can easily use the solution
- Determine what can be done about supporting captioning when an external back end (gstreamer, QuickTime, DirectShow) is in use. (MP4 containers are the most likely external back end case, so 3GPP Timed Text is a potential format candidate in that case.)
- Build test cases -- we need x testcases with y features
- Build documentation for developers and content creators
- Test solutions and file bugs in databases for each browser to drive the necessary work. Attach relevant test cases and documentation. Make sure the developers know what to fix.
Previous list that we should merge in
- Identify relevant areas of activity and individuals within the various groups focusing on Internet-based media standards and best practices. Target key points of influence and activity.
- Document the requirements for captioning and video support in the <video> element, with particular attention to whether these access features should exist internally or be synchronized externally with the media file itself.
- Introduce the basic principles of media accessibility to the thought leaders and active members of these groups. Explain and publicly document the existing media access standards and solutions (on all media dissemination platforms) and how they relate to ongoing discussions. Focus on both existing media repurposed for the Internet (i.e., originating in broadcast and cable TV environments and physical media like DVDs and theatrical motion pictures) and media originally developed for Internet distribution, including user-generated content.
- Participate in the relevant deliberations, meetings, standards development activities and proposed work products of these groups. Assure that issues of captioning (for deaf and hard-of-hearing people) and description (for blind and visually impaired people) are taken into account and understood by the developers of Internet-based media standards.
- Investigate, involve and incorporate the expressed needs and preferences of Internet-based media users with sensory disabilities.
- Disseminate project results via the communication efforts of the standards groups as well as via an NCAM web site established for posting project activities and results and for engaging with interested participants.
Measurements of Success (previous list)
- Implementation of effective and implementable media access standards within video-on-the-web standards developments
- Browser implementations which incorporate accessibility features outlined, specified, or otherwise output from groups.
- Wider awareness and understanding of media access on the Internet and greater understanding of the needs of people with disabilities as they utilize Internet-based media.