MozillaWiki - User contributions [en]

Accessibility/TextAttributes

2012-03-08T19:25:00Z

Aaronlev:

<small>[[Accessibility |<< Back to Accessibility Home Page]]</small>

Text attributes are now implemented in Firefox 3.1

This document has been superseded by the official [https://developer.mozilla.org/en/Accessibility/AT-APIs/Gecko/TextAttrs/ text attribute developer docs].

The original text attribute proposal is available in the [https://wiki.mozilla.org/index.php?title=Accessibility/TextAttributes&action=history history for this page].

Accessibility/aria/authorhelp

2011-11-08T14:47:03Z

Aaronlev: Created page with "ARIA developer resources we need/want: # Clean front page -- simpler # WCAG techniques with compatibility info and searchability # Intro materials # Videos pages # Barebones exa..."

ARIA developer resources we need/want:

# Clean front page -- simpler
# WCAG techniques with compatibility info and searchability
# Intro materials
# Videos pages
# Barebones examples
# JS library widget examples (Dojo, JQuery UI, etc.)
# Mobile ARIA
# Info on testing tools
# A "try it page" like http://www.w3schools.com/html5/

Accessibility/Original live region report

2011-11-01T21:56:48Z

Aaronlev: Created page with "<h2 name="Report_on_the_WAI_ARIA_Markup_for_AJAX_Live_Regions">Report on the WAI ARIA Markup for AJAX Live Regions</h2> <h3 name="Major_Contributors">Major Contributors</h3> <p>C..."

<h2 name="Report_on_the_WAI_ARIA_Markup_for_AJAX_Live_Regions">Report on the WAI ARIA Markup for AJAX Live Regions</h2>
<h3 name="Major_Contributors">Major Contributors</h3>
<p>Charles L. Chen</p>
<p>Aaron Leventhal</p>
<h3 name="The_Challenge:_Making_Live_Regions_Accessible">The Challenge: Making Live Regions Accessible</h3>
<p>Asynchronous JavaScript and XML (AJAX) has recently received a great amount of attention, and the number of websites using or planning to use the technique is increasing. AJAX enables web developers to easily create sites that change areas of their content in response to user actions (such as in webmail applications) or real world changes (such as updates of stock prices).</p>
<p>Screen readers, which utilize text-to-speech and Braille displays, cannot present users with as much information at the same time as visual displays, and this creates challenges which need to be addressed before AJAX can be accessible.</p>
<p>Without having information to help know which changes to speak, the tendency is to either annoy users by speaking everything which changes, or to underinform users by speaking too little. Historically, assistive technologies could not do any better than that because they did not know much about the live changes. The could receive events about where and when the changes occurred, but had a dearth of information about the relative importance to these events. Ultimately, the user experience should provide enough information for users without annoying them with extra information that they do not need.</p>
<p>Breaking down the problem, some of the specific challenges are:</p>
<ul>
<li>How should assistive technologies present live regions to users?</li>
<li>What should happen if a live region is updated while the user is reading another area of the page?</li>
<li>What should happen if two live regions are updated at the same time?</li>
<li>What information do developers need to provide about live regions, to enable a quality experience for assistive technology users</li>
</ul>
<h3 name="The_Solution:_Live_Region_Markup_and_Intuitive_User_Controls">The Solution: Live Region Markup and Intuitive User Controls</h3>
<p>The <a class="external" href="http://www.w3.org/TR/aria-state/">proposed WAI-ARIA markup for AJAX live regions</a> is designed to address these issues. Live region markup allows web page authors to specify when and how live changes to specific areas of a web page should be spoken or shown on a Braille display by a screen reader. However, the markup is not device-specific. It uses concepts such as politeness levels to indicate strategies for interruption. The same markup may also be useful for screen magnifiers or devices with small displays, which can use the information to decide what to show on the limited available screen real estate.</p>
<p>It's important to remember that none of this takes away the final decision-making role of the user. If the user does not want to hear something, they can set background changes to "quiet" or "off". Likewise, if they are missing some updates, there can be a variety of "verbose" settings.</p>
<p>That said, many users do not change settings, and will not alter the verbosity of live regions. Therefore, the live region markup is crucial, as developers need to be given the capability to provide the most optimal default behavior possible.</p>
<p>For now, the priority is to get final decisions on the live region markup. Once the markup is stable, we're planning to experiment more in-depth to find not only the optimal use of that markup, but also define a base set of user interface features and settings that give the user power without requiring them to use them, or creating unnecessary complexity.</p>
<h3 name="What_this_Report_Provides">What this Report Provides</h3>
<p>This report details Charles L. Chen's and Aaron Leventhal's findings on using the live region markup, along with links to test cases and information on the current state of Fire Vox support. The report also describes remaining issues and a set of recommendations for the live region standardization effort, to address those issues.</p>
<p>Potential readers of this report:</p>
<ul>
<li>Developers interested in affecting the emerging standard or the user experience: live region markup is still in flux.</li>
<li>End-users interested in helping shape the user experience: there are many possibilities regarding how users will interact with, and ultimately control, live regions.</li>
<li>Assistive technology developers: this report is evolving to include more recommendations for assistive technology vendors.</li>
<li>(Not) web authors: this report has not yet evolved into documentation for web authors. Practically speaking, live region markup is not yet widely supported. It does not hurt anything to add live region markup to pages, but it also won't get you much mileage from it at this point. However, this report should eventually evolve into documentation for web developers, so please check back after the release of Firefox 3.</li>
</ul>
<p>In general, any and all feedback is welcome (and encouraged) on the <a class="external" href="http://www.mozilla.org/access/#community">mailing list</a>.</p>
<h3 name="Live_Region_Attributes_and_Test_Cases">Live Region Attributes and Test Cases</h3>
<p>Please see the following sets of test cases with live region properties set:</p>
<ul>
<li><a class="external" href="http://accessibleajax.clcworld.net">CLC World test cases, which include a variety.</a></li>
<li><a class="external" href="http://test.cita.uiuc.edu/aria/live/index.php">UIUC test cases, which allow fine tuned settings for two regions on a page</a></li>
</ul>
<p>The test cases currently work with <a class="external" href="http://www.firevox.clcworld.net/downloads.html">Fire Vox</a> and <a class="external" href="http://live.gnome.org/Orca">Orca</a>.</p>
<p>In addition, Windows desktop screen readers such as JAWS and Window-Eyes do not yet (as of JAWS 9 and Window-Eyes 7 beta) utilize live region markup. Firefox 3 provides <a class="external" href="mks://localhost/en/AJAX/WAI_ARIA_Live_Regions//API_Support" title="http://developer.mozilla.org/editor/fckeditor/core/editor/en/AJAX/WAI_ARIA_Live_Regions//API_Support">API support for live regions</a>, and work is now being done by ATs to make use of that information.</p>
<h4 name="aria-live.3DPOLITENESS_SETTING"><a class="external" href="http://www.w3.org/WAI/PF/aria/#live">aria-live=POLITENESS_SETTING</a></h4>
<p>aria-live=POLITENESS_SETTING is used to set the priority with which AT should treat updates to live regions. These are only the default priority settings for live regions; AT may provide ways for users to override/change these priority settings.</p>
<table border="1" summary="aria-live=POLITENESS_SETTING">
<tbody>
<tr>
<th>Setting</th>
<th>Description</th>
<th>Example</th>
</tr>
<tr>
<td>aria-live="off"</td>
<td>This is the default. Any updates made to it should not be announced to the user. aria-live="off" would be a sensible setting for things that update very frequently such as timers that change every second.</td>
<td>
<p><a class="external" href="http://accessibleajax.clcworld.net/simple/live_off.htm">Simple Test Case for aria-live="off"</a></p>
</td>
</tr>
<tr>
<td>aria-live="polite"</td>
<td>The region is live, but updates made to it should only be announced if the user is not currently doing anything. aria-live="polite" should be used in most situations involving live regions that present new information to users, such as updating news headlines.</td>
<td>
<p><a class="external" href="http://accessibleajax.clcworld.net/simple/live_polite.htm">Simple Test Case for aria-live="polite"</a></p>
</td>
</tr>
<tr>
<td>aria-live="assertive"</td>
<td>The region is live. Updates made to it are important enough to be announced to the user as soon as possible, but it is not necessary to immediately interrupt the user. aria-live="assertive" should be used if there is information that a user should know about right away, for example, warning messages in a form that does validation on the fly.</td>
<td>
<p><a class="external" href="http://accessibleajax.clcworld.net/simple/live_assertive.htm">Simple Test Case for aria-live="assertive"</a></p>
</td>
</tr>
<tr>
<td>aria-live="rude"</td>
<td>The region is live. Updates to it are extremely important. In fact, the updates are so important that the user must be interrupted immediately. aria-live="rude" should be used sparingly and only with great consideration as it can be very annoying to users.</td>
<td>
<p><a class="external" href="http://accessibleajax.clcworld.net/simple/live_rude.htm">Simple Test Case for aria-live="rude"</a></p>
</td>
</tr>
</tbody>
</table>
<h4 name="aria-controls.3D.5BIDLIST.5D"><a class="external" href="http://www.w3.org/WAI/PF/aria/#controls">aria-controls=[IDLIST</a>]</h4>
<p>aria-controls={{mediawiki.external('IDLIST')}} is used to associate a control with the regions that it controls.</p>
<table border="1" summary="aria-controls=[IDLIST]">
<tbody>
<tr>
<th>Setting</th>
<th>Description</th>
<th>Example</th>
</tr>
<tr>
<td>aria-controls="myRegion1_IDREF myRegion2_IDREF etcEtcEtc_IDREF"</td>
<td>aria-controls={{mediawiki.external('IDLIST')}} associates an element with one or more regions that it controls. If it controls more than one region, the regions are separated by a space.
<p>When a change to one of these regions occurs because of a user action on the control, then the change should be announced immediately to let users know that their action did have an effect. At this time, Firefox automatically calculates whether an event is from user input and exposes the information to ATs. Please see the docs on <a class="external" href="mks://localhost/en/docs/AJAX:WAI_ARIA_Live_Regions/API_Support" title="en/docs/AJAX:WAI_ARIA_Live_Regions/API_Support">API support for live regions in Firefox</a>.</p>
</td>
<td>
<p><a class="external" href="http://accessibleajax.clcworld.net/simple/controls.htm">Simple Test Case for aria-controls=[IDLIST</a>]</p>
</td>
</tr>
</tbody>
</table>
<h4 name="aria-atomic.3DBOOLEAN"><a class="external" href="http://www.w3.org/WAI/PF/aria/#atomic">aria-atomic=BOOLEAN</a></h4>
<p>aria-atomic=BOOLEAN is used to set whether or not the AT should present the live region as a whole. This is only the default setting for the live region; AT may provide ways for users to override whether or not the live region is treated as atomic.</p>
<table border="1" summary="aria-atomic=BOOLEAN">
<tbody>
<tr>
<th>Setting</th>
<th>Description</th>
<th>Example</th>
</tr>
<tr>
<td>aria-atomic="false"</td>
<td>This is the default. It means that when there is a change in the region, that change can be presented on its own; the AT should not present the entire region. aria-atomic="false" is generally a good idea as it presents users with only changes and does not cause them to hear repetitive information that has not changed. However, web developers should take care that the changed information, when presented by itself, can still be understood and contextualized by the user.</td>
<td>
<p><a class="external" href="http://accessibleajax.clcworld.net/simple/atomic_false.htm">Simple Test Case for aria-atomic="false"</a></p>
</td>
</tr>
<tr>
<td>aria-atomic="true"</td>
<td>If atomic is set to "true", it means that the region must be presented as a whole; when there is a change, the AT should present the entire region, not just the change. aria-atomic="true" can make it harder for users to understand changes as the changed areas are not presented independently. aria-atomic="true" can also be annoying as it can force users to listen to repetitive information that has not changed. However, aria-atomic="true" is necessary in cases where the change, when presented by itself, cannot be understood and contexualized by the user.</td>
<td>
<p><a class="external" href="http://accessibleajax.clcworld.net/simple/atomic_true.htm">Simple Test Case for aria-atomic="true"</a></p>
</td>
</tr>
</tbody>
</table>
<h4 name="aria-labelledby.3D.5BIDLIST.5D"><a class="external" href="http://www.w3.org/WAI/PF/aria/#labelledby">aria-labelledby=[IDLIST</a>]</h4>
<p>aria-labelledby={{mediawiki.external('IDLIST')}} is used to associate a region with its labels.</p>
<table border="1" summary="aria-labelledby=[IDLIST]">
<tbody>
<tr>
<th>Setting</th>
<th>Description</th>
<th>Example</th>
</tr>
<tr>
<td>aria-labelledby="myLabel1_IDREF myLabel2_IDREF etcEtcEtc_IDREF"</td>
<td>aria-labelledby={{mediawiki.external('IDLIST')}} associates one or more elements that serve as labels with the live region that they label. These elements do not have to be HTML <label> elements. If there is more than one label, the labels are separated by a space. The labels should be presented to the user when there is a change to the region that they are associated with.</td>
<td>
<p><a class="external" href="http://accessibleajax.clcworld.net/simple/labelledby.htm">Simple Test Case for aria-labelledby=[IDLIST</a>]</p>
</td>
</tr>
</tbody>
</table>
<h4 name="aria-describedby.3D.5BIDLIST.5D"><a class="external" href="http://www.w3.org/WAI/PF/aria/#describedby">aria-describedby=[IDLIST</a>]</h4>
<p>aria-describedby={{mediawiki.external('IDLIST')}} is used to associate a region with its descriptions.</p>
<table border="1" summary="aria-describedby=[IDLIST]">
<tbody>
<tr>
<th>Setting</th>
<th>Description</th>
<th>Example</th>
</tr>
<tr>
<td>aria-describedby="myDisc1_IDREF myDisc2_IDREF etcEtcEtc_IDREF"</td>
<td>aria-describedby={{mediawiki.external('IDLIST')}} associates one or more elements that serve as descriptions with live region that they describe. If there is more than one description, the descriptions are separated by a space. The descriptions should be not be presented to the user when there is a change to the region that they are associated with as they are too lengthy and would annoy the user; however, there should be an easy way for users to find the description for a particular region when they want to find out more about the region.</td>
<td>
<p><a class="external" href="http://accessibleajax.clcworld.net/simple/describedby.htm">Simple Test Case for aria-describedby=[IDLIST</a>]</p>
</td>
</tr>
</tbody>
</table>
<h4 name="aria-relevant.3D.5BLIST_OF_CHANGES.5D"><a class="external" href="http://www.w3.org/WAI/PF/aria/#relevant">aria-relevant=[LIST_OF_CHANGES</a>]</h4>
<p>aria-relevant={{mediawiki.external('LIST_OF_CHANGES')}} is used to set what types of changes are relevant to a live region. Multiple types of changes can be listed as relevant; the types are separated by a space. The default is aria-relevant="additions text".</p>
<table border="1" summary="aria-relevant=[LIST_OF_CHANGES]">
<tbody>
<tr>
<th>Setting</th>
<th>Description</th>
<th>Example</th>
</tr>
<tr>
<td>aria-relevant="additions"</td>
<td>aria-relevant="additions" states that the insertion of nodes to the live region should be considered relevant.</td>
<td>
<p><a class="external" href="http://accessibleajax.clcworld.net/simple/relevant_additions.htm">Simple Test Case for aria-relevant="additions"</a></p>
</td>
</tr>
<tr>
<td>aria-relevant="removals"</td>
<td>aria-relevant="removals" states that the removal of nodes to the live region should be considered relevant.</td>
<td>
<p><a class="external" href="http://accessibleajax.clcworld.net/simple/relevant_removals.htm">Simple Test Case for aria-relevant="removals"</a></p>
</td>
</tr>
<tr>
<td>aria-relevant="text"</td>
<td>aria-relevant="text" states that changes to the text of nodes that already exist in the live region should be considered relevant.</td>
<td>
<p><a class="external" href="http://accessibleajax.clcworld.net/simple/relevant_text.htm">Simple Test Case for aria-relevant="text"</a></p>
</td>
</tr>
<tr>
<td>aria-relevant="all"</td>
<td>aria-relevant="all" states that all changes to the live region should be considered relevant. This is the same as doing aria-relevant="additions removals text".</td>
<td>
<p><a class="external" href="http://accessibleajax.clcworld.net/simple/relevant_all.htm">Simple Test Case for aria-relevant="all"</a></p>
</td>
</tr>
</tbody>
</table>
<h4 name="role"><a class="external" href="http://www.w3.org/WAI/PF/aria/#Using_intro">role</a></h4>
<table border="1" summary="role">
<tbody>
<tr>
<th>Setting</th>
<th>Description</th>
<th>Example</th>
</tr>
<tr>
<td>role="timer", "log", "marquee" or "status"</td>
<td>Each of those has a special meaning and a default politeness level. Please see the WAI-ARIA specification</td>
<td>   </td>
</tr>
</tbody>
</table>
<p></p>
<h3 name="Live_Changes_on_Pages_Without_WAI-ARIA_Markup">Live Changes on Pages Without WAI-ARIA Markup</h3>
<p>It is possible to still do a good job with live changes on pages where the author did not use WAI-ARIA markup. A combination of the following things can help:</p>
<ol>
<li>User settings, scripts or toggles, either global or persisted by URL</li>
<li>Timing and observation of when or how often changes occur</li>
<li>The size of the change</li>
<li>What the user is doing (how busy they are)</li>
<li>Whether the event came from user input (see the <a class="external" href="mks://localhost/en/docs/AJAX:WAI_ARIA_Live_Regions/API_Support" title="en/docs/AJAX:WAI_ARIA_Live_Regions/API_Support">live region API support docs</a>)</li>
</ol>
<p>Please test your software with <a class="external" href="http://live.gnome.org/Orca/Firefox/LiveRegions#head-6849dcb441b30982cf79ea5b155c0d4c7a686c45">web pages known to use AJAX but not live region markup</a>.</p>
<h3 name="Current_Status_of_Fire_Vox_Support">Current Status of Fire Vox Support</h3>
<table border="1" summary="Current Status: What works and what needs improvement">
<tbody>
<tr>
<th>Property</th>
<th>What works</th>
<th>Improvements needed</th>
</tr>
<tr>
<td>aria-live=POLITENESS_SETTING</td>
<td>
<p>Fire Vox supports the politeness setting.</p>
<ul>
<li>Off events are not announced.</li>
<li>Polite events are queued.</li>
<li>Assertive events will cause earlier polite events to be discarded from the queue but not earlier assertive events.</li>
<li>Rude events cause earlier polite and assertive events to be discarded from the queue.</li>
</ul>
<p>If there are too many events in the queue, Fire Vox tries to keep up as best it can with the hope that the event frequency will decrease later on - after the number of events passes a threshold, the oldest events are automatically dropped to make room for newer events. Fire Vox tries to maintain chronological consistency. Events are announced in the order in which they were fired.</p>
<p>This is the reason that less polite events will cancel events that are more polite; chronological consistency is violated if a user hears a polite event after having first heard a rude event which was fired after the polite event.</p>
<p>In addition, since most webpages are not currently marked up with WAI-ARIA properties, there is an internal value of "unknown". Under the default mode for live region announcements, Fire Vox will treat "unknown" as a politeness setting between "off" and "polite"; "unknown" events will be announced, but they can be discarded by "polite" events. Under the tagged mode for live region announcements, Fire Vox will treat "unknown" as if it were "off".</p>
<p><a class="external" href="http://accessibleajax.clcworld.net/suggested/live_missing.htm">Simple Test Case for live= is missing ("unknown")</a></p>
</td>
<td>None</td>
</tr>
<tr>
<td>aria-controls={{mediawiki.external('IDLIST')}}</td>
<td>This property is not ideal; a region can be changed both by a control or a world event.</td>
<td>
<p><a class="external" href="http://accessibleajax.clcworld.net/report.html#issues_causality">There needs to be some way to determine causality in order for AT to know whether or not it should treat a change to a region as a result of a user action on a control. </a></p>
</td>
</tr>
<tr>
<td>aria-atomic=BOOLEAN</td>
<td>Fire Vox supports the atomic property. If a region is marked as atomic, the entire region will be read out when any of its subregions are modified.</td>
<td>None</td>
</tr>
<tr>
<td>aria-labelledby={{mediawiki.external('IDLIST')}}</td>
<td>Fire Vox supports the labelledby property. When the current element is queried for more information (default: Ctrl + Shift + Q), the text contents of any labelledby elements for that current element will be read out.</td>
<td>The user has to actively query for this association; it is not actively provided, unlike the <label> property which is read as part of the identifying information of the element when it is read. The problem here is that with the HTML label element, it is possible to know when that element is first encountered that it is a label for something else. Thus the strategy is to not read a label until the item it is labelling is read. This prevents re-reading a label. However, with the labelledby property, the same algorithm is not possible; anything with an ID can potentially be a label and that cannot be determined until the item being labelled is encountered. Thus an element acting as a label because of the labelledby property cannot be skipped like an HTML label element. To svoid rereading the label and annoying the user, Fire Vox takes the approach of simply not reading the labelledby element until the user specifically tries to query for that relationship. Once the relationship can be determined available efficiently in both directions, then Fire Vox can treat labelledby elements as HTML label elements.</td>
</tr>
<tr>
<td>aria-describedby={{mediawiki.external('IDLIST')}}</td>
<td>Fire Vox supports the describedby property. When the current element is queried for more information (default: Ctrl + Shift + Q), the text contents of any describedby elements for that current element will be read out.</td>
<td>None</td>
</tr>
<tr>
<td>aria-relevant={{mediawiki.external('LIST_OF_CHANGES')}}</td>
<td>Fire Vox supports the relevant setting. Any event which is deemed to not be relevant automatically have their politeness level set to off and are not announced.</td>
<td>None</td>
</tr>
</tbody>
</table>
<h3 name="Current_Status_of_Orca_Support">Current Status of Orca Support</h3>
<table border="1" summary="Current Status: What works and what needs improvement">
<tbody>
<tr>
<th>Property</th>
<th>What works</th>
<th>Improvements needed</th>
</tr>
<tr>
<td>aria-live=POLITENESS_SETTING</td>
<td>
<p>Orca supports the politeness setting.</p>
<ul>
<li><strong>Off</strong> events are not announced.</li>
<li><strong>Polite</strong> events are queued.</li>
<li><strong>Assertive</strong> events will cause earlier polite events to be discarded from the queue but not earlier assertive events.</li>
<li><strong>Rude</strong> events cause earlier polite and assertive events to be discarded from the queue.</li>
</ul>
<p>If there are too many events in the queue, Orca tries to keep up as best it can with the hope that the event frequency will decrease later on - after the number of events passes a threshold, the oldest events are automatically dropped to make room for newer events. Orca tries to maintain chronological consistency. Events are announced in the order in which they were fired.</p>
<p>This is the reason that less polite events will cancel events that are more polite; chronological consistency is violated if a user hears a polite event after having first heard a rude event which was fired after the polite event.</p>
<p>Orca also supports no ARIA markup cases and identifies document changes as live region events. In addition, Orca provides the user a set of controls to change the politeness of a live region and the ability to save these changes for later visits.</p>
<p></p>
</td>
<td>None</td>
</tr>
<tr>
<td>aria-controls={{mediawiki.external('IDLIST')}}</td>
<td>Orca does not support aria-controls.</td>
<td>Currently not implemented.</td>
</tr>
<tr>
<td>aria-atomic=BOOLEAN</td>
<td>Orca supports the atomic property.</td>
<td>None</td>
</tr>
<tr>
<td>aria-labelledby={{mediawiki.external('IDLIST')}}</td>
<td>Orca supports the labelledby property. Currently this information is provided with the live region content. However, there are some issues when labeling with spans and currently there is no support for multiple labels. See Firefox bugs.</td>
<td>None</td>
</tr>
<tr>
<td>aria-describedby={{mediawiki.external('IDLIST')}}</td>
<td>Orca supports the describedby property as part of the "where am I" function.</td>
<td>None</td>
</tr>
<tr>
<td>aria-relevant={{mediawiki.external('LIST_OF_CHANGES')}}</td>
<td>Orca does not currently recognize aria-relevant</td>
<td>Currently not implemented.</td>
</tr>
</tbody>
</table>
<h3 name="Issues_and_Proposed_Solutions">Issues and Proposed Solutions</h3>
<table border="1" summary="Issues: Problems and suggested solutions">
<tbody>
<tr>
<th>Issue</th>
<th>Problem Description</th>
<th>Proposed Solution</th>
</tr>
<tr>
<td id="issues_causality">1. Causality</td>
<td>The AT will need some way to know whether a control is really controlling a live region or if the onChange event for a particular control and an update to a live region that it controls is merely a coincidence (imagine a user tabbing out of the input blank after having typed something but without pressing enter and having some other user send a message at about the same time - both events happened, but the change in the input blank was not the cause for the new message that appeared in the blank).</td>
<td>In Mozilla, this is now provided via the "event-from-user-input" object attribute via the nsIAccessible interface. See <a href="mks://localhost/en/AJAX/WAI_ARIA_Live_Regions//API_Support" title="en/AJAX/WAI_ARIA_Live_Regions//API_Support">AJAX:WAI_ARIA_Live_Regions/API_Support</a> for more information.</td>
</tr>
<tr>
<td>2. Interim updates</td>
<td>If an update is polite, it is unclear whether or not it should cause the earlier updates for the same region in the queue to be discarded. In the case of updates made to a live region that displays the most recent play made in a game, polite events about the play just made should not cause earlier events to be discarded; to get a full picture of how the game is unfolding, one must know what the earlier plays were. So in this case, the user should be allowed to lag behind while many plays are being made and then catch up when there is a time out or some other pause in the action. However, in the case of updates to a stock price, the current price is what matters and its price three or two or one minute ago is of no interest; thus, polite updates to the stock price should cause earlier events to be discarded.</td>
<td>
<p>Since understanding the purpose behind the updates is crucial to determining whether or not earlier events should be discarded, web developers should have the ability to set the default for whether the AT should treat interim events for a particular live region as relevant or if only the final announcement-time content is relevant.</p>
<p>Adding "interim" as a keyword for relevant would solve this problem. If "interim" is added, then all relevant events to the live region which have happened since the last announcement will be announced. However, if "interim" is not specified, then only the events which are currently reflected in the page will be announced.</p>
<p>This means that without "interim", if the events queue have a node being added and then having its text changed, the announcement will only announce the current state of that node's text - the original text that it had when it was first added will not be announced since that is not there anymore. If "interim" had been used in this case, then there would have been an announcement that the node was added which gives its original text, followed by another announcement that the node was updated which gives its current text.</p>
<p>Note that interim's control over whether later events cause earlier events to be discarded is orthogonal to what is controlled by aria-live=POLITENESS_SETTING. Assertive and rude events will still discard earlier events which are more polite than themselves, regardless of the interim setting. Whether a polite event will discard earlier polite events for the same region depends on the interim setting; a polite event will never discard earlier polite events from other regions.</p>
<p>Although adding the value of "interim" to the relevant property is still being discussed, Fire Vox already supports it.</p>
<p><a class="external" href="http://accessibleajax.clcworld.net/suggested/relevant_interim.htm">Simple Test Case for aria-relevant="interim additions text"</a></p>
</td>
</tr>
<tr>
<td>3. Batching events</td>
<td>Sometimes, a web developer may make a series of related changes in quick succession. Announcing them as separate events would confuse the user, and the time it takes for the changes to happen is dependent on the user's machine and the network. Additionally, a connection may time out or have some other error; thus, it is possible to have a series of updates that is only partially completed and unable to finish.</td>
<td>The web developer should have a way to specify whether a live region is busy. Adding aria-busy={true/false/error} would solve this problem. aria-busy="true" means that the live region is in the middle of a set of changes and that no events should be announced yet. aria-busy="false" means that the live region is done with its set of updates. aria-busy="error" means that an error has occurred and that the full set of updates will not be completed. The default is aria-busy="false"; thus, if nothing is specified, then by default, events to live regions are ready to be announced when they happen.</td>
</tr>
<tr>
<td>4. Setting a threshold on event frequency</td>
<td>With events that come from world events, the frequency of the events could vary dramatically in some cases. Too many events at once would make it very difficult for AT users to keep up and could lead to cognitive overload.</td>
<td>In most real world situations where there can suddenly be a string of updates, it is the same set of information that is being updated. Good examples would be stocks and game stats. In both of these cases, interim should not be set as only the current values matter. As a result, users should not fall too far behind. To address the problem of cognitive overload (especially if the user is multitasking), AT should provide a patience setting that allows users to restrict updates to only once every X seconds.</td>
</tr>
<tr>
<td>5. Higher level abstractions for web developers</td>
<td>Having to specify the live region properties for each widget on a page can be tedious; it also increases the chances for human error.</td>
<td>Web developers should be able to use WAI-ARIA Roles as a higher level abstraction for specifying the live region properties. Roles such as "log", "alert", "progressbar", etc. should have a default set of live region properties associated with them in the WAI-ARIA standard. These default properties can be overridden by explicitly specifying them.</td>
</tr>
<tr>
<td>6. Browser support</td>
<td>Browsers only give AT relatively low level information. For example, when the textContent of an HTML node is changed, the DOM mutation events that are fired are "DOMNodeRemoved" followed by "DOMNodeInserted". It is currently up to the AT to piece together these two bits of information and deduce that what has really happened is a text change event.</td>
<td>AT vendors need more information and better abstractions from browsers. In the case of the textContent changing and two separate events being fired, the browser can clearly tell that it is a textContent change rather than an old element being removed from the page and then a new element being added. That information should be given to the AT directly since that will be more accurate and less computationally expensive than having the AT try to figure all of this out for itself.</td>
</tr>
<tr>
<td>7. Style changes are not fired as DOM events</td>
<td>If we developers dynamically show/hide elements by changing the style on the elements, ATs that look at the DOM will not be able to detect when such a change has occurred since there is no DOM event fired. This is a problem for elements on the page which from a user's point of view, are essentially added or removed via changes to the display or visibility property.</td>
<td>The DOM spec should provide for the firing of events when style has been changed.</td>
</tr>
<tr>
<td>8. Notifications</td>
<td>Some notifications should be spoken before regular messages without causing the regular messages to be dropped. An example of such a notification is a chat message that is directed at the user. In such a case, that message should be spoken before the other chat messages, but the other chat messages should still be spoken and not just dropped. Some AT users have both speech synthesis and Braille - they may prefer assertive notifications to be delivered to the Braille display while regular messages are spoken by the synthesizer.</td>
<td>
<p>If multiple hardware channels are available, the AT should allow users to map the live events to different channels.</p>
</td>
</tr>
</tbody>
</table>
<h3 name="Status_of_ATK.2FAT-SPI_and_IAccessible2_Support">Status of ATK/AT-SPI and IAccessible2 Support in Firefox</h3>
<p>There is quite a lot of API support in Firefox 3 for live regions. Please read <a href="mks://localhost/en/AJAX/WAI_ARIA_Live_Regions//API_Support" title="en/AJAX/WAI_ARIA_Live_Regions//API_Support">AJAX:WAI_ARIA_Live_Regions/API_Support</a> for more information.</p>
<h3 name="Recommendations_for_authors">Recommendations for authors</h3>
<p>Please see the <a class="external" href="http://www.w3.org/WAI/PF/aria-practices/#LiveRegions">live region section in the Best Practices Guide</a>.</p>
<h3>Recommendations for screen reader developers</h3>
<p>Please see the <a class="external" href="mks://localhost/en/ARIA/ARIA_Screen_Reader_Implementors_Guide#Live_Regions" title="http://developer.mozilla.org/editor/fckeditor/core/editor/En/ARIA_Screen_Reader_Implementors_Guide#Live_Regions">live region section in the ARIA Screen Reader Implementors Guide</a>.</p>
<h3>Recommendations for browser implementors</h3>
<p>Please see <a class="external" href="mks://localhost/en/ARIA_User_Agent_Implementors_Guide#11.3.12_Changes_to_document_content_or_node_visibility" title="http://developer.mozilla.org/editor/fckeditor/core/editor/en/ARIA_User_Agent_Implementors_Guide#11.3.12_Changes_to_document_content_or_node_visibility">changes to document content or node visibility</a>in the ARIA user agent implementors guide.</p>

Accessibility/Math Accessibility

2009-01-14T09:04:46Z

Aaronlev:

= Background info =
* [http://www.utdallas.edu/~gupta/mathaccsurvey.pdf Math and accessibility survey] -- excellent paper on presenting math in Braille or text-to-speech

= Braille math codes =

[http://chezdom.net/blog/?page_id=51 Source of information]

* Nemeth (United States, Cambodia, Canada, India, Indonesia, Iran, Israel, Laos, Lebanon, Malaysia, New Zealand, Pakistan, Philippines, Saudi Arabia, Sri Lanka, Thailand, Vietnam, and Western Samoa.
* Nemeth with modifications for Greek (Greece)
* UEBC (Australia, New Zealand, Nigeria and South Africa)
* British (U.K.)
* Marburg (Germany, Austria, Poland)
* Modified Marburg Braille for Chinese (China)
* Stuttgart (8 dot Braille, used with German Braille, not common)
* Lambda (8 dot Braille, also used as intermediate translation medium)
* French
* Italian
* Spanish
* Japanese
* Bharati code (India)
* Israeli

= Math translation libraries =
{| summary="Braille math translation libraries" width="90%" border="1" cellspacing="1" cellpadding="1"
! Project
! License
! Coded in
! Input
! Output
|-
| [http://code.google.com/p/liblouisxml/ liblouisxml]
| LGPL
| C
| MathML
| Nemeth, Marburg, British
|-
| [http://sourceforge.net/projects/latex-access latex-access]
| GPL
| Python
| TeX/LaTeX
| Nemeth. Also does TTS.
|-
| [http://www.ascience.eu/?q=en/finalConf/abstractArchambault UMCL]
| LGPL
| C and XSLT
| MathML, working on TeX/LaTeX
| French (including 3 versions), Marburg, British, Nemeth and Italian
|-
| [http://brltex.sourceforge.net/ BrlTex]
| RPL (Reciprocal)
| Python
| TeX
| British
|-
| [http://code.google.com/p/xtrans/ xtrans]
|
| Java
| HTML
| HTML
|-
| [http://sourceforge.net/projects/mathtran/ MathTran]
| GPL
| Python
| MathML or TeX
| TeX or MathML (no Braille)
|-
| [http://www.lambdaproject.org/ Lambda]
| Proprietary
| Unknown
| MathML?
| Lambda code, Nemeth and "the most popular European national codes"
|-
| MAVIS/Duxbury
| Proprietary
| Unknown
| TeX
| Nemeth, British, UEBC and French
|-
| [http://www.webelmediatronics.in/wimats.htm WIMATS]
| Proprietary
| Unknown
| Unknown
| Nemeth
|}

Accessibility/Math Accessibility

2009-01-14T08:58:20Z

Aaronlev:

Background info:
* [http://www.utdallas.edu/~gupta/mathaccsurvey.pdf Math and accessibility survey] -- excellent paper on presenting math in Braille or text-to-speech

[http://chezdom.net/blog/?page_id=51 Braille math codes]:
* Nemeth (United States, Cambodia, Canada, India, Indonesia, Iran, Israel, Laos, Lebanon, Malaysia, New Zealand, Pakistan, Philippines, Saudi Arabia, Sri Lanka, Thailand, Vietnam, and Western Samoa.
* Nemeth with modifications for Greek (Greece)
* UEBC (Australia, New Zealand, Nigeria and South Africa)
* British (U.K.)
* Marburg (Germany, Austria, Poland)
* Modified Marburg Braille for Chinese (China)
* Stuttgart (8 dot Braille, used with German Braille, not common)
* Lambda (8 dot Braille, also used as intermediate translation medium)
* French
* Italian
* Spanish
* Japanese
* Bharati code (India)
* Israeli

Math translation libraries:
{| summary="Braille math translation libraries" width="90%" border="1" cellspacing="1" cellpadding="1"
! Project
! License
! Coded in
! Input
! Output
|-
| [http://code.google.com/p/liblouisxml/ liblouisxml]
| LGPL
| C
| MathML
| Nemeth, Marburg, British
|-
| [http://sourceforge.net/projects/latex-access latex-access]
| GPL
| Python
| TeX/LaTeX
| Nemeth. Also does TTS.
|-
| [http://www.ascience.eu/?q=en/finalConf/abstractArchambault UMCL]
| LGPL
| C and XSLT
| MathML, working on TeX/LaTeX
| French (including 3 versions), Marburg, British, Nemeth and Italian
|-
| [http://brltex.sourceforge.net/ BrlTex]
| RPL (Reciprocal)
| Python
| TeX
| British
|-
| [http://code.google.com/p/xtrans/ xtrans]
|
| Java
| HTML
| HTML
|-
| [http://sourceforge.net/projects/mathtran/ MathTran]
| GPL
| Python
| MathML or TeX
| TeX or MathML (no Braille)
|-
| [http://www.lambdaproject.org/ Lambda]
| Proprietary
| Unknown
| MathML?
| Lambda code, Nemeth and "the most popular European national codes"
|-
| MAVIS/Duxbury
| Proprietary
| Unknown
| TeX
| Nemeth, British, UEBC and French
|-
| [http://www.webelmediatronics.in/wimats.htm WIMATS]
| Proprietary
| Unknown
| Unknown
| Nemeth
|}

Accessibility/Math Accessibility

2009-01-12T22:31:00Z

Aaronlev:

Background info:
* [http://www.utdallas.edu/~gupta/mathaccsurvey.pdf Math and accessibility survey] -- excellent paper on presenting math in Braille or text-to-speech

[http://chezdom.net/blog/?page_id=51 Braille math codes]:
* Nemeth (United States, Canada, India, Iran, Israel, Lebanon, New Zealand, Pakistan, Saudi Arabia, Sri Lanka, Thailand, USA and Western Samoa.
* Nemeth with modifications for Greek (Greece)
* UEBC (Australia, New Zealand, Nigeria and South Africa)
* British (U.K.)
* Marburg (Germany, Austria, Poland)
* Modified Marburg Braille for Chinese (China)
* Stuttgart (8 dot Braille, used with German Braille, not common)
* Lambda (8 dot Braille, also used as intermediate translation medium)
* French
* Italian
* Spanish
* Japanese
* Bharati code (India)
* Israeli

Math translation libraries:
{| summary="Braille math translation libraries" width="90%" border="1" cellspacing="1" cellpadding="1"
! Project
! License
! Coded in
! Input
! Output
|-
| [http://code.google.com/p/liblouisxml/ liblouisxml]
| LGPL
| C
| MathML
| Nemeth, Marburg, British
|-
| [http://sourceforge.net/projects/latex-access latex-access]
| GPL
| Python
| TeX/LaTeX
| Nemeth. Also does TTS.
|-
| [http://www.ascience.eu/?q=en/finalConf/abstractArchambault UMCL]
| LGPL
| C and XSLT
| MathML, working on TeX/LaTeX
| French (including 3 versions), Marburg, British, Nemeth and Italian
|-
| [http://brltex.sourceforge.net/ BrlTex]
| RPL (Reciprocal)
| Python
| TeX
| British
|-
| [http://code.google.com/p/xtrans/ xtrans]
|
|
|
|
|-
| [http://sourceforge.net/projects/mathtran/ MathTran]
| GPL
| Python
| MathML or TeX
| TeX or MathML (no Braille)
|-
| [http://www.lambdaproject.org/ Lambda]
| Proprietary
| Unknown
| MathML?
| Lambda code, Nemeth and "the most popular European national codes"
|-
| MAVIS/Duxbury
| Proprietary
| Unknown
| TeX
| Nemeth, British, UEBC and French
|}

Accessibility/Math Accessibility

2009-01-12T22:12:11Z

Aaronlev:

[http://chezdom.net/blog/?page_id=51 Braille math codes]:
* Nemeth (United States, Canada, India, Iran, Israel, Lebanon, New Zealand, Pakistan, Saudi Arabia, Sri Lanka, Thailand, USA and Western Samoa.
* Nemeth with modifications for Greek (Greece)
* UEBC (Australia, New Zealand, Nigeria and South Africa)
* British (U.K.)
* Marburg (Germany, Austria, Poland)
* Modified Marburg Braille for Chinese (China)
* Stuttgart (8 dot Braille, used with German Braille, not common)
* Lambda (8 dot Braille, also used as intermediate translation medium)
* French
* Italian
* Spanish
* Japanese
* Bharati code (India)
* Israeli

Braille math translation libraries:
{| summary="Braille math translation libraries" width="90%" border="1" cellspacing="1" cellpadding="1"
! Project
! License
! Coded in
! Input
! Output
|-
| [http://code.google.com/p/liblouisxml/ liblouisxml]
| LGPL
| C
| MathML
| Nemeth, Marburg, British
|-
| [http://sourceforge.net/projects/latex-access latex-access]
| GPL
| Python
| TeX/LaTeX
| Nemeth. Also does TTS.
|-
| UMCL
| LGPL
| C and XSLT
| MathML, working on TeX/LaTeX
| French (including 3 versions), Marburg, British, Nemeth and Italian
|-
| [http://brltex.sourceforge.net/ BrlTex]
| RPL (Reciprocal)
| Python
| TeX
| British
|-
| [http://code.google.com/p/xtrans/ xtrans]
|
|
|
|
|-
| [http://www.lambdaproject.org/ Lambda]
| Proprietary
| Unknown
| MathML?
| Lambda code, Nemeth and "the most popular European national codes"
|-
| MAVIS/Duxbury
| Proprietary
| Unknown
| TeX
| Nemeth, British, UEBC and French
|}

Accessibility/Math Accessibility

2009-01-12T22:10:32Z

Aaronlev:

Accessibility/Math Accessibility

2009-01-12T22:05:32Z

Aaronlev:

[http://chezdom.net/blog/?page_id=51 Braille math codes]:
* Nemeth (United States, Canada, India, Iran, Israel, Lebanon, New Zealand, Pakistan, Saudi Arabia, Sri Lanka, Thailand, USA and Western Samoa.
* Nemeth with modifications for Greek (Greece)
* UEBC (Australia, New Zealand, Nigeria and South Africa)
* British (U.K.)
* Marburg (Germany, Austria, Poland)
* Modified Marburg Braille for Chinese (China)
* Stuttgart (8 dot Braille, used with German Braille, not common)
* Lambda (8 dot Braille, also used as intermediate translation medium)
* French
* Italian
* Spanish
* Japanese
* Bharati code (India)
* Israeli

Braille math translation libraries:
{| summary="Braille math translation libraries" width="90%" border="1" cellspacing="1" cellpadding="1"
! Project
! License
! Coded in
! Input
! Output
|-
| [http://code.google.com/p/liblouisxml/ liblouisxml]
| LGPL
| C
| MathML
| Nemeth, Marburg, British
|-
| [http://sourceforge.net/projects/latex-access latex-access]
| GPL
| Python
| TeX/LaTeX
| Nemeth. Also does TTS.
|-
| UMCL
| LGPL
| C and XSLT
| MathML, working on TeX/LaTeX
| French (including 3 versions), Marburg, British, Nemeth and Italian
|-
| Labradoor
|
|
|
|
|-
| [http://www.lambdaproject.org/ Lambda]
| Proprietary
| Unknown
| MathML?
| Lambda code, Nemeth and "the most popular European national codes"
|-
| MAVIS/Duxbury
| Proprietary
| Unknown
| TeX
| Nemeth
|-
| [http://code.google.com/p/xtrans/ xtrans]
|
|
|
|
|}

Accessibility/Math Accessibility

2009-01-12T21:52:26Z

Aaronlev:

[http://chezdom.net/blog/?page_id=51 Braille math codes]:
* Nemeth (United States, Canada, India, Iran, Israel, Lebanon, New Zealand, Pakistan, Saudi Arabia, Sri Lanka, Thailand, USA and Western Samoa.
* Nemeth with modifications for Greek (Greece)
* UEBC (Australia, New Zealand, Nigeria and South Africa)
* British (U.K.)
* Marburg (Germany, Austria, Poland)
* Modified Marburg Braille for Chinese (China)
* Stuttgart (8 dot Braille, used with German Braille, not common)
* Lambda(8 dot Braille, also used as intermediate translation medium)
* French
* Italian
* Spanish
* Japanese
* Bharati code (India)
* Israeli

Braille math translation libraries:
{| summary="Braille math translation libraries" width="90%" border="1" cellspacing="1" cellpadding="1"
! Project
! License
! Coded in
! Sources
! Targets
|-
| [http://code.google.com/p/liblouisxml/ liblouisxml]
| LGPL
| C
| MathML
| Nemeth, Marburg, British
|-
| [http://sourceforge.net/projects/latex-access latex-access]
| GPL
| Python
| TeX/LaTeX
| Nemeth. Also does TTS.
|-
| UMCL
| LGPL
|
|
|
|-
| Labradoor
|
|
|
|
|-
| LAMBDA
| Proprietary
| Unknown
|
|
|}

Accessibility/Math Accessibility

2009-01-12T21:51:42Z

Aaronlev:

[http://chezdom.net/blog/?page_id=51 Braille math codes]:
* Nemeth (United States, Canada, India, Iran, Israel, Lebanon, New Zealand, Pakistan, Saudi Arabia, Sri Lanka, Thailand, USA and Western Samoa.
* Nemeth with modifications for Greek (Greece)
* UEBC (Australia, New Zealand, Nigeria and South Africa)
* British (U.K.)
* Marburg (Germany, Austria, Poland)
* Modified Marburg Braille for Chinese (China)
* Stuttgart (8 dot Braille, used with German Braille, not common)
* Lambda(8 dot Braille, also used as intermediate translation medium)
* French
* Italian
* Spanish
* Japanese
* Bharati code (India)
* Israeli

Braille math translation libraries:
{| summary="Braille math translation libraries" width="90%" border="1" cellspacing="1" cellpadding="1"
! Project
! License
! Coded in
! Sources
! Targets
|-
| [liblouisxml http://code.google.com/p/liblouisxml/]
| LGPL
| C
| MathML
| Nemeth, Marburg, British
|-
| [http://sourceforge.net/projects/latex-access latex-access]
| GPL
| Python
| TeX/LaTeX
| Nemeth. Also does TTS.
|-
| UMCL
| LGPL
|
|
|
|-
| Labradoor
|
|
|
|
|-
| LAMBDA
| Proprietary
| Unknown
|
|
|}

Accessibility/Math Accessibility

2009-01-12T21:40:09Z

Aaronlev:

Braille math codes:
* Nemeth (North America)
* UEBC (Australia)
* British
* Marburg (Germany)
* French

Braille math translation libraries:
{| summary="Braille math translation libraries" width="90%" border="1" cellspacing="1" cellpadding="1"
! Project
! License
! Coded in
! Sources
! Targets
|-
| [liblouisxml http://code.google.com/p/liblouisxml/]
| LGPL
| C
| MathML
| Nemeth, Marburg, British
|-
| [http://sourceforge.net/projects/latex-access latex-access]
| GPL
| Python
| TeX/LaTeX
| Nemeth. Also does TTS.
|-
| UMCL
| LGPL
|
|
|
|-
| Labradoor
|
|
|
|
|-
| LAMBDA
| Proprietary
| Unknown
|
|
|}

Accessibility/Math Accessibility

2009-01-12T21:17:22Z

Aaronlev:

Braille math codes:
* Nemeth (North America)
* UEBC (Australia)
* British
* Marburg (Germany)
* French

Braille math translation libraries:
{| summary="Braille math translation libraries" width="90%" border="1" cellspacing="1" cellpadding="1"
! Project
! License
! Coded in
! Sources
! Targets
|-
| liblouis-xml
| LGPL
| C
| MathML
| Nemeth, Marburg, British
|-
| latex-access
|
|
|
|
|-
| UMCL
| LGPL
|
|
|
|-
| Labradoor
|
|
|
|
|-
| LAMBDA
| Proprietary
| Unknown
|
|
|}

Accessibility/Math Accessibility

2009-01-12T21:14:10Z

Aaronlev: New page: Braille math codes: * Nemeth: North America * UEBC: Australia * British maths: UK Braille math translation libraries: {| summary="Braille math translation libraries" width="90%" border="1...

Braille math codes:
* Nemeth: North America
* UEBC: Australia
* British maths: UK

Braille math translation libraries:
{| summary="Braille math translation libraries" width="90%" border="1" cellspacing="1" cellpadding="1"
! Project
! License
! Coded in
! Sources
! Targets
|-
| liblouis-xml
|
|
|
|
|-
| latex-access
|
|
|
|
|-
| UMCL
| LGPL
|
|
|
|-
| Labradoor
|
|
|
|
|}

Accessibility

2009-01-12T20:56:09Z

Aaronlev: /* Mozilla Accessibility Wiki */

= Mozilla Accessibility Wiki =

* General
** [http://developer.mozilla.org/en/docs/Accessibility Development Center] - documentation on various accessibility initiatives, XUL authoring guidelines, ARIA, AT-SPI, web development and more
**[[Accessibility/Learning_Disabilities|Learning Disabilities]] - resources related to learning disabilities
** [[Accessibility/Testing|Testing Center]] - the latest on Mozilla accessibility testing, test plans, environments, top bugs, and more.

* Sections
**[[Mac:Accessibility| Mac Accessibility]] - home page of accessibility support on Mac.
** [[Accessibility/AT-Windows-API|Windows Accessibility]] - this FAQ explains how makers of Windows screen readers, voice dictation packages and magnification software can support Gecko-based software. The article is targeted on MSAA.
**[[Accessibility/XForms|XForms Accessibility]] - AT API support for XForms elements.

* Drafts
**[[Accessibility/Attributes|Attributes]] - proposed AT API attribute support.
**[[Accessibility/TextAttributes|Text Attributes]] - proposed AT API text attribute support.
**[[Accessibility/Datatypes|ARIA Type Attributes]] - proposed ARIA data type attributes to object attribute mapping
**[[Accessibility/AJAX:WAI_ARIA_Live_Region_Library|AJAX: WAI ARIA Live Region Library]]
**[[Accessibility/Accessible_Table_Implementation|Accessible Table Implementation]]
**[[Accessibility/IA2ToGecko|Mapping IAccessible2 to Gecko]]
**[[Accessibility/CustomWidgets|Custom widgets accessibility]]

* Project Coordination
**[[Accessibility/Firefox3|Firefox3]] - the list of meta bugs targeted to Firefox 3
**[[Accessibility/csun2009|CSUN 2009]] - Mozilla CSUN 2008 Activities
**[[Accessibility/Projects|Potential Accessibility Projects]]
**[[Accessibility/PlanMozilla2|Mozilla 2 accessibility plans]]
**[[Accessibility/ARIA_Coordination|ARIA coordination]]
**[[Accessibility/Video_Accessibility|Video accessibility]]
**[[Accessibility/Math_Accessibility|Math accessibility]]

Accessibility

2009-01-12T20:51:23Z

Aaronlev: /* Mozilla Accessibility Wiki */

= Mozilla Accessibility Wiki =

* General
** [http://developer.mozilla.org/en/docs/Accessibility Development Center] - documentation on various accessibility initiatives, XUL authoring guidelines, ARIA, AT-SPI, web development and more
**[[Accessibility/Learning_Disabilities|Learning Disabilities]] - resources related to learning disabilities
** [[Accessibility/Testing|Testing Center]] - the latest on Mozilla accessibility testing, test plans, environments, top bugs, and more.

* Sections
**[[Mac:Accessibility| Mac Accessibility]] - home page of accessibility support on Mac.
** [[Accessibility/AT-Windows-API|Windows Accessibility]] - this FAQ explains how makers of Windows screen readers, voice dictation packages and magnification software can support Gecko-based software. The article is targeted on MSAA.
**[[Accessibility/XForms|XForms Accessibility]] - AT API support for XForms elements.

* Drafts
**[[Accessibility/Attributes|Attributes]] - proposed AT API attribute support.
**[[Accessibility/TextAttributes|Text Attributes]] - proposed AT API text attribute support.
**[[Accessibility/Datatypes|ARIA Type Attributes]] - proposed ARIA data type attributes to object attribute mapping
**[[Accessibility/AJAX:WAI_ARIA_Live_Region_Library|AJAX: WAI ARIA Live Region Library]]
**[[Accessibility/Accessible_Table_Implementation|Accessible Table Implementation]]
**[[Accessibility/IA2ToGecko|Mapping IAccessible2 to Gecko]]
**[[Accessibility/CustomWidgets|Custom widgets accessibility]]

* Project Coordination
**[[Accessibility/Firefox3|Firefox3]] - the list of meta bugs targeted to Firefox 3
**[[Accessibility/csun2008|CSUN 2008]] - Mozilla CSUN 2008 Activities
**[[Accessibility/Projects|Potential Accessibility Projects]]
**[[Accessibility/PlanMozilla2|Mozilla 2 accessibility plans]]
**[[Accessibility/ARIA_Coordination|ARIA coordination]]
**[[Accessibility/Video_Accessibility|Video accessibility]]
**[[Accessibility/Math_Accessibility|Math accessibility]]

Accessibility/JSON ARIA

2009-01-07T12:30:57Z

Aaronlev: /* XUL, SVG */

=Role extensibility=

This is a proposal for how authors could define new ARIA widgets.

=Problem statement=

The basic problem is that every accessibility API today has a predefined set of roles and properties. Historically, because developers are always creating new things, they end up forcing the new semantics into the existing semantics in inappropriate ways, just to get the behavior they want in one or two ATs they test with. This degrades the accessibility API over time as other ATs end up writing special case code for the various semantics on a per-application basis.

For example, an application may make their software work alright with JAWS, by putting additional status information into aria-describedby. However, this will not work well with changes to the status if the widget is later used dynamically, and will not work with alternative input technology.

Another issue is that standards bodies are slow, and that proprietary vendors do not want to spend the resources to painfully push their new ideas through the standards. In addition, it can be a problem to share IP in the new widgets before the release of a new product.

== Use cases ==

No one wants useless bloat, so the plan is to let ARIA 1.0 settle in and prove that it's necessary and usable via prototyping.

Here are some areas we will be developing use cases for:

* Vendor-specific widgets
* New innovations
* Areas that are too detailed and specific for standardization, but useful for accessibility (such as buddylists or scheduling widgets)
* Diagrams, where the visual appearance (color, dashed lines, whatever) often indicates properties

=How does it work?=

A new reusable role is defined by an author or organization via JSON.

The definition includes the following information:
# What other role can it be treated as (inheritance)?
# What properties does it have, and what is the type of each property
# The localization strings necessary to present the object as text
# How to treat property changes
# Which properties can be set by the user

=Status of the discussion=

This is a rough proposal for what the community may decide is not necessary, and even if we do it, we'll be waiting until after ARIA 1.0.

* There is still skepticism of whether this is necessary
* There are proponents of it among the vendor and accessibiltiy communities
* The idea has been run by the leads on Firefox accessibility, as well as the Orca and NVDA screen reader projects, and they believe it is feasible

We will be looking to get as many use cases that we can -- specifically we'll need widgets that ARIA 1.0 does not cover which this technology would help define.

= Authoring new roles =
== Pointing to new roles definitions from within document content==
===HTML===
<pre>
<head>
<link rel="ARIA" href="http://www.myroles.org/buddy.json"/>
<link rel="ARIA" "http://www.myroles.org/buddylist.json"/>

<link rel="ARIA-l10n" href="http://www.myroles.org/buddy-l10n.json"/>
<link rel="ARIA-l10n" href="http://www.myroles.org/buddylist-l10n.json"/>
</head>
</pre>

===XUL, SVG===

XUL and SVG don't define the <link> tag, an open question is how the roles can be included in such documents.

* One suggestion is to create a new processing instruction like: <code> <?xml-aria href="chrome://calendar/content/access/roles.json" type="text/json"?></code>
* Also, since XUL has XBL, and this is effectively a new widget, we could require that it be a new element. The nsIAccessibleProvider interface used in XBL could be extended to provide a property that points to the JSON file. Or, in XBL we could actually directly define the properties that would have been in the JSON.
** Fallen: processing instruction has the advantage that its a more general form of inclusion, which could possibly lead to allowing aria extensions for any type of XML document. Aaron: I think we might want to allow either. If XBL is available though I suggest to put it there as part of widget definition.
** Fallen: In XBL, we could probably use the <resources> block to add something, i.e:
<pre>
<binding id="foobar">
<resources>
<stylesheet src="chrome://calendar/skin/foosheet.css"/>
<aria-roles src="chrome://calendar/content/access/roles.json/>
<aria-roles src="chrome://calendar/locale/access/roles-l10n.json" l10n="true"/>
</resources>
...
</binding>
</pre>

== Authoring content with the new widget ==

<pre>
<div role="buddylist listbox secondary">
<div role="buddy option" aria-away="true" aria-idle="3 hours, 22 minutes" aria-where="mobile" aria-friends="somefriend"/>
</pre>

The author only needs to include the fallback role that we inherit from (in this case listbox or option) if they
need support for browser version that support ARIA but don't support role extensibility. Browsers that support
role extensibility should utilize the "inherits" field from the JSON file.

If you care about validation, you need to write a DTD or schema that handles the new properties.

== Defining the widget ==

Example: buddy widget
The definition is in a [http://en.wikipedia.org/wiki/JavaScript_Object_Notation JSON file], which is easy for any modern browser to parse into an object.

<pre>
{


"role": "buddy",

"inherits": "listbox",




"nameOkFromContents": true,

"activeProperties": [




[ "away", "boolean" ],
[ "activity", "string", "What is this user doing?" ],
],

"editableProperties":





[ "ignored", "boolean" ],

"passiveProperties": [ 

[ "idle", "string" ], 
[ "where", [ "pc", "mobile", "blackberry"] ], 
[ "friends", "IDREF" ], 
]



"localizedRole": "Buddy",

"localizedProperties": [

"friends", "Friends with"
]

"localizedValues": [



[ "ignored", [[ "true", "User blocked" ],
[ "false", "" ],
[ "away", [[ "true", "Currently away"],
[ "false", "Available" ]],
[ "where", [[ "pc", "At desk" ],
[ "mobile", "On phone"],
[ "blackberry", "On blackberry" ]]
]
}
</pre>

= End user experience =

== Screen reader users ==
Screen reader users would be able to hear the role of the new type of object, and associated properties.

Property changes:
* If the object is focused, then any properties in the activeProperties or liveProperties would be spoken
* If the object is not focused, then any properties in the liveProperties would be treated as a polite change

== Alternative input ==

If a property is listed under editableProperties, then it is the author's responsibility to handle mutation events and change the state of the widget based on changes to the ARIA attribute.

An alternative input device (an on screen keyboard, voice input software or even a cell phone browser) may choose to provide alternative methods for data entry that are more suitable for that environment. The web page must watch DOMAttrModified (onpropertychange in IE) and map that to the widget state.

= How to process =

There are 3 ways an AT can handle a new role:
# Basic accessibility: just fall back on the role it inherits from -- this is not wrong, but does not offer large improvements
# Good accessibility: use the provided JSON semantics for the role and its properties. It describes what to present when the object receives focus, and what to present when an attribute changes.
# Enhanced accessibility: via special application code for new role
#* User or vendor-defined AT scripts that operate on a per-webpage or per-role basis
#* If role becomes commonly used across the web, new versions of the core AT can deliver built-in support

== Accessibility API Support (ATK/AT-SPI and IAccessible2) ==

Need to fill this out -- we can either:
# use object attributes and events to indicate changed attributes, or
# develop new interfaces to expose the custom role information

Using a11y API events may be an issue, in terms of specifying which property has changed. We need either event data or a listener/callback mechanism. Need to think about this.

Accessibility/JSON ARIA

2009-01-07T12:12:57Z

Aaronlev: /* XUL, SVG */

=Role extensibility=

This is a proposal for how authors could define new ARIA widgets.

=Problem statement=

The basic problem is that every accessibility API today has a predefined set of roles and properties. Historically, because developers are always creating new things, they end up forcing the new semantics into the existing semantics in inappropriate ways, just to get the behavior they want in one or two ATs they test with. This degrades the accessibility API over time as other ATs end up writing special case code for the various semantics on a per-application basis.

For example, an application may make their software work alright with JAWS, by putting additional status information into aria-describedby. However, this will not work well with changes to the status if the widget is later used dynamically, and will not work with alternative input technology.

Another issue is that standards bodies are slow, and that proprietary vendors do not want to spend the resources to painfully push their new ideas through the standards. In addition, it can be a problem to share IP in the new widgets before the release of a new product.

== Use cases ==

No one wants useless bloat, so the plan is to let ARIA 1.0 settle in and prove that it's necessary and usable via prototyping.

Here are some areas we will be developing use cases for:

* Vendor-specific widgets
* New innovations
* Areas that are too detailed and specific for standardization, but useful for accessibility (such as buddylists or scheduling widgets)
* Diagrams, where the visual appearance (color, dashed lines, whatever) often indicates properties

=How does it work?=

A new reusable role is defined by an author or organization via JSON.

The definition includes the following information:
# What other role can it be treated as (inheritance)?
# What properties does it have, and what is the type of each property
# The localization strings necessary to present the object as text
# How to treat property changes
# Which properties can be set by the user

=Status of the discussion=

This is a rough proposal for what the community may decide is not necessary, and even if we do it, we'll be waiting until after ARIA 1.0.

* There is still skepticism of whether this is necessary
* There are proponents of it among the vendor and accessibiltiy communities
* The idea has been run by the leads on Firefox accessibility, as well as the Orca and NVDA screen reader projects, and they believe it is feasible

We will be looking to get as many use cases that we can -- specifically we'll need widgets that ARIA 1.0 does not cover which this technology would help define.

= Authoring new roles =
== Pointing to new roles definitions from within document content==
===HTML===
<pre>
<head>
<link rel="ARIA" href="http://www.myroles.org/buddy.json"/>
<link rel="ARIA" "http://www.myroles.org/buddylist.json"/>

<link rel="ARIA-l10n" href="http://www.myroles.org/buddy-l10n.json"/>
<link rel="ARIA-l10n" href="http://www.myroles.org/buddylist-l10n.json"/>
</head>
</pre>

===XUL, SVG===

XUL and SVG don't define the <link> tag, an open question is how the roles can be included in such documents.

* One suggestion is to create a new processing instruction like: <code> <?xml-aria href="chrome://calendar/content/access/roles.json" type="text/json"?></code> (Note from Aaron, can we do this on a role by role basis for SVG? We have that advantage in the link solution for HTML)
* Also, since XUL has XBL, and this is effectively a new widget, we could require that it be a new element. The nsIAccessibleProvider interface used in XBL could be extended to provide a property that points to the JSON file. Or, in XBL we could actually directly define the properties that would have been in the JSON.

== Authoring content with the new widget ==

<pre>
<div role="buddylist listbox secondary">
<div role="buddy option" aria-away="true" aria-idle="3 hours, 22 minutes" aria-where="mobile" aria-friends="somefriend"/>
</pre>

The author only needs to include the fallback role that we inherit from (in this case listbox or option) if they
need support for browser version that support ARIA but don't support role extensibility. Browsers that support
role extensibility should utilize the "inherits" field from the JSON file.

If you care about validation, you need to write a DTD or schema that handles the new properties.

== Defining the widget ==

Example: buddy widget
The definition is in a [http://en.wikipedia.org/wiki/JavaScript_Object_Notation JSON file], which is easy for any modern browser to parse into an object.

<pre>
{


"role": "buddy",

"inherits": "listbox",




"nameOkFromContents": true,

"activeProperties": [




[ "away", "boolean" ],
[ "activity", "string", "What is this user doing?" ],
],

"editableProperties":





[ "ignored", "boolean" ],

"passiveProperties": [ 

[ "idle", "string" ], 
[ "where", [ "pc", "mobile", "blackberry"] ], 
[ "friends", "IDREF" ], 
]



"localizedRole": "Buddy",

"localizedProperties": [

"friends", "Friends with"
]

"localizedValues": [



[ "ignored", [[ "true", "User blocked" ],
[ "false", "" ],
[ "away", [[ "true", "Currently away"],
[ "false", "Available" ]],
[ "where", [[ "pc", "At desk" ],
[ "mobile", "On phone"],
[ "blackberry", "On blackberry" ]]
]
}
</pre>

= End user experience =

== Screen reader users ==
Screen reader users would be able to hear the role of the new type of object, and associated properties.

Property changes:
* If the object is focused, then any properties in the activeProperties or liveProperties would be spoken
* If the object is not focused, then any properties in the liveProperties would be treated as a polite change

== Alternative input ==

If a property is listed under editableProperties, then it is the author's responsibility to handle mutation events and change the state of the widget based on changes to the ARIA attribute.

An alternative input device (an on screen keyboard, voice input software or even a cell phone browser) may choose to provide alternative methods for data entry that are more suitable for that environment. The web page must watch DOMAttrModified (onpropertychange in IE) and map that to the widget state.

= How to process =

There are 3 ways an AT can handle a new role:
# Basic accessibility: just fall back on the role it inherits from -- this is not wrong, but does not offer large improvements
# Good accessibility: use the provided JSON semantics for the role and its properties. It describes what to present when the object receives focus, and what to present when an attribute changes.
# Enhanced accessibility: via special application code for new role
#* User or vendor-defined AT scripts that operate on a per-webpage or per-role basis
#* If role becomes commonly used across the web, new versions of the core AT can deliver built-in support

== Accessibility API Support (ATK/AT-SPI and IAccessible2) ==

Need to fill this out -- we can either:
# use object attributes and events to indicate changed attributes, or
# develop new interfaces to expose the custom role information

Using a11y API events may be an issue, in terms of specifying which property has changed. We need either event data or a listener/callback mechanism. Need to think about this.

Accessibility/Video Codecs

2008-09-22T10:38:04Z

Aaronlev: /* Software support */

== Introduction to Video ==

A video consists of multiple tracks of data temporally multiplexed (or: interleaved) with each other such that at any point in time the data from all tracks relevant to that time is not "far away". To be a video, there has to be at least a video track and a audio track. There can be, however, multiple audio tracks (e.g. multiple languages), multiple video tracks (e.g. different camera angles), multiple timed text tracks (e.g. subtitles in different languages), and other tracks, such as timed images (e.g. slides of a presentation) or lighting information for a concert etc.

To multiplex these multiple tracks of data together into one file (or stream), there is a container (or encapsulation format).

To compress high bandwidth content such as video or audio into a smaller file, there are codecs (encoder/decoder).

Thus, the simplest video with a caption consists of a container, a video codec, an audio codec and captions that have been multiplexed as a timed text codec.

As an aside: captions (or subtitles) can also be created for videos by "burning" them into the video. However, to re-access such captions, e.g. in order to do searches, requires OCR. In modern digital times, that is not a preferred way of dealing with captions and will not be regarded here.

== Software support ==

Desktop environments support video codecs through [http://en.wikipedia.org/wiki/Multimedia_framework media frameworks]. A media framework is a piece of software that provides media decoding (and sometimes encoding) and rendering support to application programmers. A media framework typically consists of a set of filters that are put together into a filter network to perform the task.

For example, to decode a Ogg Theora/Vorbis video file, you would need filters to read the file, strip off the Ogg encapsulation, de-multiplex the codec tracks, decode the Theora video, decode the Vorbis audio, send the decoded video to a given display area, and the decoded audio to the sound device, and make sure the synchronisation is still given.

Media frameworks are usually very flexible in their codec and container format support, because filters are built such that they can easily connect to each other. Also, it is easy to extend support for a new container format or codec by adding the libraries for these formats to the system and adding a plugin to the framework that adds the filters.

It is through the [http://www.xiph.org/dshow/ OggCodecs filters] that the Microsoft Windows [http://en.wikipedia.org/wiki/DirectShow DirectShow] media framework receives support for Ogg Theora.

It is through the [http://www.xiph.org/quicktime/ XiphQT components] that the Apple [http://en.wikipedia.org/wiki/QuickTime QuickTime] media framework receives support for Ogg Theora.

{| summary="Frameworks by platform" border="1"
! Desktop
! Framework
|-
| Windows
| DirectShow
|-
| Mac OS X
| QuickTime
|-
| Gnome
| GStreamer
|-
| KDE
| Phonon
|}

== Choosing a Caption Format ==

For a given container, you need to have a defined mapping for multiplexing a data stream for a given codec into the container. This mapping specification also needs to be supported by tools, frameworks, and applications - in particular video players.

In theory, given a multiplexing rule, you can put any video codec and any captioning format in any container. However, multiplexing rules don't exist for all codec/container combinations.

Instead, video codecs tends to have a conventional native container and the choice of video codec dictates the container and audio codec to use. By choosing Ogg Theora as a baseline codec, the native container format is Ogg and the native audio codecs are one of Vorbis, Speex, or FLAC.

{| summary="Map of video technology for the web" border="1"
! Container
! Codecs
! Authoring tools
! Natural captioning format
|-
| Ogg
|
* Theora (video)
* Vorbis (audio)
|
| CMML, Kate
|-
| MP4
| H.264
|
| 3GPP Timed Text
|-
| .flv
| VP6, H.264
|
| W3C TT
|-
| WMV
| WMV9/VC-1
|
|
|}

The Flash plug-in effectively provides a specialized playback framework for .flv and .mp4 containers. Gecko embeds an Ogg-specific playback framework called liboggplay. It only supports the Ogg container format.

In theory, different containers also have different conventional timed text formats. MPEG-4 for example supports W3C TimedText, while Flash supports a proprietary CuePoints format (http://www.actionscript.org/resources/articles/518/1/Creating-subtitles-for-flash-video-using-XML/Page1.html) and a simple version of W3C TimedText (http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/TimedTextTags.html).

While the situation is fairly fixed for codecs inside the Ogg container (more from a political/legal standpoint rather than technical, actually), Ogg hasn't chosen one conventional native caption codec format yet. Instead, the Ogg community has experimented with several formats, amongst them CMML and Kate.

Another project called OGM actually branched the Ogg codebase and implemented support for a wide range of proprietary and non-free codecs. For example, OGM files most often carry video encoded in the MPEG-4 ASP format and audio in Vorbis or AC-3 together with subtitles in SRT, SSA or VobSub format.

== Ogg Background ==

Ogg is a container format for time-continuous data, which interleaves audio and video tracks and any other time-continuously sampled data stream into one flat file.

Ogg is being developed by Xiph.org. Xiph.org have not made a decision yet on how subtitles and captions are best to be supported inside Ogg.

Ogg itself supports CMML, the Continuous Media Markup Language which is HTML-like and includes support for hyperlinks. It has been considered for captions and subtitles, but the specifications are still in development.

It has to be re-assessed under the current accessibility requirements whether CMML or an extended version of CMML is a useful solution to accessibility problems. A very interesting implementation and use of many of the CMML/Annodex ideas is MetavidWiki (see http://metavid.ucsc.edu/), which is an open source wiki-style social annotation authoring tool.

Further, Ogg recently added Kate, a codec for karaoke with animated text and images. Kate defines its own file format for specifying karaoke and animations. Experience from the implementation of Kate needs to be included in an accessibility solution for Ogg.

There is currently no implementation of W3C Timed Text (TT) for Ogg or of any of the other subtitling formats.

== What is involved with creating a caption format for Ogg ==

Definition of inclusion of a text stream such as W3C TT into Ogg requires a so-called media mapping:

* definition of the format of the codec bitstream, i.e. what packets of data are being encoded and how do they fit into Ogg pages

* definition of the format of the codec header pages

This enables multiplexing of the data stream into the Ogg container.

At this stage we are not clear which format to use. The solution may be found in one format that supports all the requirements, or in multiple formats with the provisioning of a framework for how to implement and interrelate these formats with each other. We may potentially need to cover new ground, create a new specification and promote it into the different relevant communities. Or the best solution may be to support one of the existing subtitling formats and extend it to cover other accessibility needs.

Also, there needs to be a recommendation for how to display the different text codecs on screen, such that a standard means of display for the different types is achieved. E.g. audio annotations are not to be displayed as text, but rather be rendered through a text-to-speech, etc.

As for the implementation of support for a new text codec, there is a whole swag of software to be extended.

To enable support for a text codec in Firefox requires an extension to liboggz, liboggplay and to the Mozilla adaptation code. The adaption code is in the implementation of the WHATWG HTMLMediaElement, HTMLAudioElement and HTMLVideoElement. Basically, the implementation of those DOM objects uses liboggplay functions to decode the data and get the video and audio data. So liboggplay would need functions to extract the decoded caption information. As well as the liboggplay support there would need to be some way of getting the information from the web developer side. That is, DOM methods or events. Implementing those would use the liboggplay functionality that would be added.

To enable support for Desktop use requires support in the OggDSF DirectShow filter, in the XiphQT Quicktime components, in mplayer, vlc, gstreamer, phonon, and xine. Support of these media frameworks has a follow-on effect in that it also creates support for video players, video applications, and Web Browsers that rely on native platform media frameworks to decode video such as Safari.

To enable authoring requires support for ffmpeg, ffmpeg2theora, and further GUI authoring applications to be determined.

Accessibility/TextAttributes

2008-09-12T09:15:33Z

Aaronlev: Ensure people use correct docs

<small>[[Accessibility |<< Back to Accessibility Home Page]]</small>

Text attributes are now implemented in Firefox 3.1

This document has been superseded by the official [http://developer.mozilla.org/en/Accessibility/AT-APIs#Supported_Text_Attributes text attribute developer docs].

The original text attribute proposal is available in the [https://wiki.mozilla.org/index.php?title=Accessibility/TextAttributes&action=history history for this page].

Accessibility/TextAttributes

2008-09-10T08:59:56Z

Aaronlev: /* Linux Foundation Proposed (ATK + IA2) */

<small>[[Accessibility |<< Back to Accessibility Home Page]]</small>

= Introduction =

This article is targeted to reflect a support of text attributes by Gecko accessibility API. There is no implementation in Gecko yet. This is a draft of specification how we will do it.

= Proposed API =

== Summary ==

The following method returns a collection of text attributes at the given offset, and calculates the range where returned attributes are stretched.

{| summary="Method to get text attributes" border="1" cellspacing="1" cellpadding="1"
! API
! Attributes for a text range
! Attributes for entire object
|-
| Internal XPCOM
|
<pre style="margin-left: 0; padding-left: 0; border: 0; background-color: white;">
nsIPersistentProperties
getTextAttributes(in long offset,
out long rangeStartOffset,
out long rangeEndOffset);</pre>
|
<pre style="margin-left: 0; padding-left: 0; border: 0; background-color: white;">
nsIPersistentProperties
getDefaultTextAttributes();</pre>
|-
| IAccessible2
|
<pre style="margin-left: 0; padding-left: 0; border: 0; background-color: white;">
HRESULT
get_attributes(in long offset,
long *rangeStartOffset,
long *rangeEndOFfset,
BSTR *textAttributes);</pre>
|
Not supported:

Combined into get_attributes() results.

|-
| AT-SPI
|
<pre style="margin-left: 0; padding-left: 0; border: 0; background-color: white;">
string
getAttributes(in long offset,
out long *rangeStartOffset,
out long *rangeEndOffset);</pre>
|
<pre style="margin-left: 0; padding-left: 0; border: 0; background-color: white;">
string getDefaultAttributes();</pre>
|}

== Parameters (for getTextAttributes/get_attributes/getAttributes) ==

; offset
: [in] the given offset

; rangeStartOffset
: [out] the start offset of the result range

; rangeEndOffset
: [out] the end offset of the result range

Ranges are not nested. They are consecutive, so that AT's always know when to ask for the next range. For example, for text 'abc<b>def</b>ghi', there are three ranges (0, 3), (3, 6) and (6, 9).

== Return Value for both methods ==

A collection of text attributes (the list of pairs consisted from name and value). All text attributes that apply to the current range are exposed, but in order to conserve the amount of data passed, most text attributes will have reasonable defaults and will not be exposed in the list when they are equal to the default. For example, if font-style is "normal" it will not be exposed in the return value. See the list of text attributes below to find the defaults.

The IA2 and ATK/AT-SPI return value is a single strange in the format name:value;name:value;name:value etc.

= Events =

When a certain text attribute is changed then the internal event 'EVENT_TEXT_ATTRIBUTE_CHANGED' should be fired.

In IA2, there is no data to specify what attribute changed, and for what offsets. Therefore, the AT must cache attributes of any objects that it will want to know about text attribute changes for. For example, it can cache the the text attribute ranges for the current text accessible, and compare the previous text attribute runs with the current text attribute runs.

Events will be fired for the topic object to which they apply, in order to avoid floods of too many events. For example, if someone selects all and then boldfaces the selection -- every object in the accessible tree is essentially getting an attribute change. We will reduce the number of events by only firing the text attribute change event on the root accessible for the change.

For Firefox 3, events will not be fired for style changes that are not caused by DOM changes. At the moment we are focused on the rich text editing use case. For rich text editing there will always be a DOM change.

= List of supported attributes =

== Linux Foundation Proposed (ATK + IA2) ==

Note: the following characters in names and values need to be escaped with a backslash: backslash, colon, comma, equals, and semicolon.

{| summary="Proposed Text Attributes" width="90%" border="1" cellspacing="1" cellpadding="1"
! Attribute name
! Attribute description
! Default value if attribute not exposed
|-
| auto-generated
| "true" for list bullet/numbering text or layout-inserted text (such as via CSS pseudo styles :before or :after)
| false
|-
| background-color
| Background color as <code>rgb(<i>r</i>,<i>g</i>,<i>b</i>)</code> where <i>r</i>, <i>g</i> and <i>b</i> are 0-255
| transparent
|-
| color
| Foreground color as <code>rgb(<i>r</i>,<i>g</i>,<i>b</i>)</code> where <i>r</i>, <i>g</i> and <i>b</i> are 0-255
| rgb(0,0,0)
|-
| font-family
| The computed font name
| no default, always specified
|-
| font-size
| Font size in points
| no default, always specified
|-
| font-style
| italic (oblique not currently supported)
| normal
|-
| font-weight
| The computed font weight (100, 200, 300, 400, 500, 600, 700, 800, 900; normal = 400, bold = 700, bolder = 900)
| 400
|-
| invalid
| "spelling" if it is marked by the inline spell checker for being incorrectly spelled. Attribute not present in all other cases. Also can support "grammar" or "true" (generally invalid but no reason given) since aria-invalid can be used to mark up any span, and aria-invalid must map to this.
| Not misspelled or invalid in any way
|-
| language
| What language is this text in, e.g. en-US (do we want this or do we use IA2::locale and make sure each locale change gets separate accessible object?) We purposely call this language and not lang, to be in line with the [http://www.linuxfoundation.org/en/Accessibility/IAccessible2/TextAttributes IA2 text attributes spec].
| en-US
|-
| text-line-through-style
| solid (only exposed if if there is a line through)
| no line through
|-
| text-underline-style
| solid (only exposed if if there is an underline)
| no underline
|-
| text-align
| left/center/right/justify
| left
|-
| text-indent
| [#]mm where [#] is the number of millimeters (max precision = 1/100 of a millimeter). The text "mm" must come after the number.
| 0 = no indent
|-
| text-position (for sup/sub)
| super/sub (translate from values in vertical-align)
| none
|-
| writing-mode
| rl or lr (we don't support tb - top to bottom)
| lr
|}

== Currently unsupported ==

The following text attributes, which are in the [http://www.linux-foundation.org/en/Accessibility/IAccessible2/TextAttributes IAccessible2 text attribute specification], are not currently supported due to today's limitations of text formatting on the web:

* text-line-through-mode
* text-line-through-type
* text-line-through-width
* text-outline
* text-shadow
* text-underline-type
* text-underline-width
* text-underline-mode

The following object attribute in IA2 is not supported, because we support it via text attributes in a different way:
* list (with sub-attributes style, level & prefix) -- the list bullet text is exposed via the accessible text interface, with the text attribute static=true

The following IA2 object attributes are not supported, but potentially could be if asked for. We may need them to fully support online word processors, but need to think about how to pass on the true intentions of the word processor at that place in the text. In fact, it is currently possible for the word processor to specify these on any object by prepending aria- to the object attribute name and simply insert the attribute on the appropriate element.
* line-height
* line-spacing
* text-align
* text-indent
* margin-left, margin-top, margin-right, margin-bottom: these object attributes are not supported, because the related browser CSS attributes have nothing to do with page margins as the IA2 object attributes do. In Mozilla the bounds of an object can be used to find where it is located.

= References =

* [http://www.linux-foundation.org/en/Accessibility/IAccessible2/TextAttributes IA2 Text Attributes] - IAccessible2 Text Attributes Documentation

Accessibility/TextAttributes

2008-09-10T08:58:44Z

Aaronlev: /* Gecko specific */

<small>[[Accessibility |<< Back to Accessibility Home Page]]</small>

= Introduction =

This article is targeted to reflect a support of text attributes by Gecko accessibility API. There is no implementation in Gecko yet. This is a draft of specification how we will do it.

= Proposed API =

== Summary ==

The following method returns a collection of text attributes at the given offset, and calculates the range where returned attributes are stretched.

{| summary="Method to get text attributes" border="1" cellspacing="1" cellpadding="1"
! API
! Attributes for a text range
! Attributes for entire object
|-
| Internal XPCOM
|
<pre style="margin-left: 0; padding-left: 0; border: 0; background-color: white;">
nsIPersistentProperties
getTextAttributes(in long offset,
out long rangeStartOffset,
out long rangeEndOffset);</pre>
|
<pre style="margin-left: 0; padding-left: 0; border: 0; background-color: white;">
nsIPersistentProperties
getDefaultTextAttributes();</pre>
|-
| IAccessible2
|
<pre style="margin-left: 0; padding-left: 0; border: 0; background-color: white;">
HRESULT
get_attributes(in long offset,
long *rangeStartOffset,
long *rangeEndOFfset,
BSTR *textAttributes);</pre>
|
Not supported:

Combined into get_attributes() results.

|-
| AT-SPI
|
<pre style="margin-left: 0; padding-left: 0; border: 0; background-color: white;">
string
getAttributes(in long offset,
out long *rangeStartOffset,
out long *rangeEndOffset);</pre>
|
<pre style="margin-left: 0; padding-left: 0; border: 0; background-color: white;">
string getDefaultAttributes();</pre>
|}

== Parameters (for getTextAttributes/get_attributes/getAttributes) ==

; offset
: [in] the given offset

; rangeStartOffset
: [out] the start offset of the result range

; rangeEndOffset
: [out] the end offset of the result range

Ranges are not nested. They are consecutive, so that AT's always know when to ask for the next range. For example, for text 'abc<b>def</b>ghi', there are three ranges (0, 3), (3, 6) and (6, 9).

== Return Value for both methods ==

A collection of text attributes (the list of pairs consisted from name and value). All text attributes that apply to the current range are exposed, but in order to conserve the amount of data passed, most text attributes will have reasonable defaults and will not be exposed in the list when they are equal to the default. For example, if font-style is "normal" it will not be exposed in the return value. See the list of text attributes below to find the defaults.

The IA2 and ATK/AT-SPI return value is a single strange in the format name:value;name:value;name:value etc.

= Events =

When a certain text attribute is changed then the internal event 'EVENT_TEXT_ATTRIBUTE_CHANGED' should be fired.

In IA2, there is no data to specify what attribute changed, and for what offsets. Therefore, the AT must cache attributes of any objects that it will want to know about text attribute changes for. For example, it can cache the the text attribute ranges for the current text accessible, and compare the previous text attribute runs with the current text attribute runs.

Events will be fired for the topic object to which they apply, in order to avoid floods of too many events. For example, if someone selects all and then boldfaces the selection -- every object in the accessible tree is essentially getting an attribute change. We will reduce the number of events by only firing the text attribute change event on the root accessible for the change.

For Firefox 3, events will not be fired for style changes that are not caused by DOM changes. At the moment we are focused on the rich text editing use case. For rich text editing there will always be a DOM change.

= List of supported attributes =

== Linux Foundation Proposed (ATK + IA2) ==

Note: the following characters in names and values need to be escaped with a backslash: backslash, colon, comma, equals, and semicolon.

{| summary="Proposed Text Attributes" width="90%" border="1" cellspacing="1" cellpadding="1"
! Attribute name
! Attribute description
! Default value if attribute not exposed
|-
| auto-generated
| "true" for list bullet/numbering text or layout-inserted text (such as via CSS pseudo styles :before or :after)
| false
|-
| background-color
| Background color as <code>rgb(<i>r</i>,<i>g</i>,<i>b</i>)</code> where <i>r</i>, <i>g</i> and <i>b</i> are 0-255
| transparent
|-
| color
| Foreground color as <code>rgb(<i>r</i>,<i>g</i>,<i>b</i>)</code> where <i>r</i>, <i>g</i> and <i>b</i> are 0-255
| rgb(0,0,0)
|-
| font-family
| The computed font name
| no default, always specified
|-
| font-size
| Font size in points
| no default, always specified
|-
| font-style
| italic (oblique not currently supported)
| normal
|-
| font-weight
| The computed font weight (100, 200, 300, 400, 500, 600, 700, 800, 900; normal = 400, bold = 700, bolder = 900)
| 500
|-
| language
| What language is this text in, e.g. en-US (do we want this or do we use IA2::locale and make sure each locale change gets separate accessible object?) We purposely call this language and not lang, to be in line with the [http://www.linuxfoundation.org/en/Accessibility/IAccessible2/TextAttributes IA2 text attributes spec].
| en-US
|-
| text-line-through-style
| solid (only exposed if if there is a line through)
| no line through
|-
| text-underline-style
| solid (only exposed if if there is an underline)
| no underline
|-
| text-align
| left/center/right/justify
| left
|-
| text-indent
| [#]mm where [#] is the number of millimeters (max precision = 1/100 of a millimeter). The text "mm" must come after the number.
| 0 = no indent
|-
| text-position (for sup/sub)
| super/sub (translate from values in vertical-align)
| none
|-
| writing-mode
| rl or lr (we don't support tb - top to bottom)
| lr
|}

== Currently unsupported ==

The following text attributes, which are in the [http://www.linux-foundation.org/en/Accessibility/IAccessible2/TextAttributes IAccessible2 text attribute specification], are not currently supported due to today's limitations of text formatting on the web:

* text-line-through-mode
* text-line-through-type
* text-line-through-width
* text-outline
* text-shadow
* text-underline-type
* text-underline-width
* text-underline-mode

The following object attribute in IA2 is not supported, because we support it via text attributes in a different way:
* list (with sub-attributes style, level & prefix) -- the list bullet text is exposed via the accessible text interface, with the text attribute static=true

The following IA2 object attributes are not supported, but potentially could be if asked for. We may need them to fully support online word processors, but need to think about how to pass on the true intentions of the word processor at that place in the text. In fact, it is currently possible for the word processor to specify these on any object by prepending aria- to the object attribute name and simply insert the attribute on the appropriate element.
* line-height
* line-spacing
* text-align
* text-indent
* margin-left, margin-top, margin-right, margin-bottom: these object attributes are not supported, because the related browser CSS attributes have nothing to do with page margins as the IA2 object attributes do. In Mozilla the bounds of an object can be used to find where it is located.

= References =

* [http://www.linux-foundation.org/en/Accessibility/IAccessible2/TextAttributes IA2 Text Attributes] - IAccessible2 Text Attributes Documentation

Accessibility/TextAttributes

2008-09-10T08:57:12Z

Aaronlev: /* Currently unsupported */

<small>[[Accessibility |<< Back to Accessibility Home Page]]</small>

= Introduction =

This article is targeted to reflect a support of text attributes by Gecko accessibility API. There is no implementation in Gecko yet. This is a draft of specification how we will do it.

= Proposed API =

== Summary ==

The following method returns a collection of text attributes at the given offset, and calculates the range where returned attributes are stretched.

{| summary="Method to get text attributes" border="1" cellspacing="1" cellpadding="1"
! API
! Attributes for a text range
! Attributes for entire object
|-
| Internal XPCOM
|
<pre style="margin-left: 0; padding-left: 0; border: 0; background-color: white;">
nsIPersistentProperties
getTextAttributes(in long offset,
out long rangeStartOffset,
out long rangeEndOffset);</pre>
|
<pre style="margin-left: 0; padding-left: 0; border: 0; background-color: white;">
nsIPersistentProperties
getDefaultTextAttributes();</pre>
|-
| IAccessible2
|
<pre style="margin-left: 0; padding-left: 0; border: 0; background-color: white;">
HRESULT
get_attributes(in long offset,
long *rangeStartOffset,
long *rangeEndOFfset,
BSTR *textAttributes);</pre>
|
Not supported:

Combined into get_attributes() results.

|-
| AT-SPI
|
<pre style="margin-left: 0; padding-left: 0; border: 0; background-color: white;">
string
getAttributes(in long offset,
out long *rangeStartOffset,
out long *rangeEndOffset);</pre>
|
<pre style="margin-left: 0; padding-left: 0; border: 0; background-color: white;">
string getDefaultAttributes();</pre>
|}

== Parameters (for getTextAttributes/get_attributes/getAttributes) ==

; offset
: [in] the given offset

; rangeStartOffset
: [out] the start offset of the result range

; rangeEndOffset
: [out] the end offset of the result range

Ranges are not nested. They are consecutive, so that AT's always know when to ask for the next range. For example, for text 'abc<b>def</b>ghi', there are three ranges (0, 3), (3, 6) and (6, 9).

== Return Value for both methods ==

A collection of text attributes (the list of pairs consisted from name and value). All text attributes that apply to the current range are exposed, but in order to conserve the amount of data passed, most text attributes will have reasonable defaults and will not be exposed in the list when they are equal to the default. For example, if font-style is "normal" it will not be exposed in the return value. See the list of text attributes below to find the defaults.

The IA2 and ATK/AT-SPI return value is a single strange in the format name:value;name:value;name:value etc.

= Events =

When a certain text attribute is changed then the internal event 'EVENT_TEXT_ATTRIBUTE_CHANGED' should be fired.

In IA2, there is no data to specify what attribute changed, and for what offsets. Therefore, the AT must cache attributes of any objects that it will want to know about text attribute changes for. For example, it can cache the the text attribute ranges for the current text accessible, and compare the previous text attribute runs with the current text attribute runs.

Events will be fired for the topic object to which they apply, in order to avoid floods of too many events. For example, if someone selects all and then boldfaces the selection -- every object in the accessible tree is essentially getting an attribute change. We will reduce the number of events by only firing the text attribute change event on the root accessible for the change.

For Firefox 3, events will not be fired for style changes that are not caused by DOM changes. At the moment we are focused on the rich text editing use case. For rich text editing there will always be a DOM change.

= List of supported attributes =

== Gecko specific ==

{| summary="Gecko Specific Text Attributes" width="90%" border="1" cellspacing="1" cellpadding="1"
! Attribute name
! Attribute description
! Default value if attribute not exposed
|-
| invalid
| "spelling" if it is marked by the inline spell checker for being incorrectly spelled. Attribute not present in all other cases. Also can support "grammar" or "true" since aria-invalid can be used to mark up any span, and aria-invalid must map to this.
| Not misspelled or invalid in any way
|}

== Linux Foundation Proposed (ATK + IA2) ==

Note: the following characters in names and values need to be escaped with a backslash: backslash, colon, comma, equals, and semicolon.

{| summary="Proposed Text Attributes" width="90%" border="1" cellspacing="1" cellpadding="1"
! Attribute name
! Attribute description
! Default value if attribute not exposed
|-
| auto-generated
| "true" for list bullet/numbering text or layout-inserted text (such as via CSS pseudo styles :before or :after)
| false
|-
| background-color
| Background color as <code>rgb(<i>r</i>,<i>g</i>,<i>b</i>)</code> where <i>r</i>, <i>g</i> and <i>b</i> are 0-255
| transparent
|-
| color
| Foreground color as <code>rgb(<i>r</i>,<i>g</i>,<i>b</i>)</code> where <i>r</i>, <i>g</i> and <i>b</i> are 0-255
| rgb(0,0,0)
|-
| font-family
| The computed font name
| no default, always specified
|-
| font-size
| Font size in points
| no default, always specified
|-
| font-style
| italic (oblique not currently supported)
| normal
|-
| font-weight
| The computed font weight (100, 200, 300, 400, 500, 600, 700, 800, 900; normal = 400, bold = 700, bolder = 900)
| 500
|-
| language
| What language is this text in, e.g. en-US (do we want this or do we use IA2::locale and make sure each locale change gets separate accessible object?) We purposely call this language and not lang, to be in line with the [http://www.linuxfoundation.org/en/Accessibility/IAccessible2/TextAttributes IA2 text attributes spec].
| en-US
|-
| text-line-through-style
| solid (only exposed if if there is a line through)
| no line through
|-
| text-underline-style
| solid (only exposed if if there is an underline)
| no underline
|-
| text-align
| left/center/right/justify
| left
|-
| text-indent
| [#]mm where [#] is the number of millimeters (max precision = 1/100 of a millimeter). The text "mm" must come after the number.
| 0 = no indent
|-
| text-position (for sup/sub)
| super/sub (translate from values in vertical-align)
| none
|-
| writing-mode
| rl or lr (we don't support tb - top to bottom)
| lr
|}

== Currently unsupported ==

The following text attributes, which are in the [http://www.linux-foundation.org/en/Accessibility/IAccessible2/TextAttributes IAccessible2 text attribute specification], are not currently supported due to today's limitations of text formatting on the web:

* text-line-through-mode
* text-line-through-type
* text-line-through-width
* text-outline
* text-shadow
* text-underline-type
* text-underline-width
* text-underline-mode

The following object attribute in IA2 is not supported, because we support it via text attributes in a different way:
* list (with sub-attributes style, level & prefix) -- the list bullet text is exposed via the accessible text interface, with the text attribute static=true

The following IA2 object attributes are not supported, but potentially could be if asked for. We may need them to fully support online word processors, but need to think about how to pass on the true intentions of the word processor at that place in the text. In fact, it is currently possible for the word processor to specify these on any object by prepending aria- to the object attribute name and simply insert the attribute on the appropriate element.
* line-height
* line-spacing
* text-align
* text-indent
* margin-left, margin-top, margin-right, margin-bottom: these object attributes are not supported, because the related browser CSS attributes have nothing to do with page margins as the IA2 object attributes do. In Mozilla the bounds of an object can be used to find where it is located.

= References =

* [http://www.linux-foundation.org/en/Accessibility/IAccessible2/TextAttributes IA2 Text Attributes] - IAccessible2 Text Attributes Documentation

Accessibility/TextAttributes

2008-09-10T08:52:50Z

Aaronlev: /* Linux Foundation Proposed (ATK + IA2) */

<small>[[Accessibility |<< Back to Accessibility Home Page]]</small>

= Introduction =

This article is targeted to reflect a support of text attributes by Gecko accessibility API. There is no implementation in Gecko yet. This is a draft of specification how we will do it.

= Proposed API =

== Summary ==

The following method returns a collection of text attributes at the given offset, and calculates the range where returned attributes are stretched.

{| summary="Method to get text attributes" border="1" cellspacing="1" cellpadding="1"
! API
! Attributes for a text range
! Attributes for entire object
|-
| Internal XPCOM
|
<pre style="margin-left: 0; padding-left: 0; border: 0; background-color: white;">
nsIPersistentProperties
getTextAttributes(in long offset,
out long rangeStartOffset,
out long rangeEndOffset);</pre>
|
<pre style="margin-left: 0; padding-left: 0; border: 0; background-color: white;">
nsIPersistentProperties
getDefaultTextAttributes();</pre>
|-
| IAccessible2
|
<pre style="margin-left: 0; padding-left: 0; border: 0; background-color: white;">
HRESULT
get_attributes(in long offset,
long *rangeStartOffset,
long *rangeEndOFfset,
BSTR *textAttributes);</pre>
|
Not supported:

Combined into get_attributes() results.

|-
| AT-SPI
|
<pre style="margin-left: 0; padding-left: 0; border: 0; background-color: white;">
string
getAttributes(in long offset,
out long *rangeStartOffset,
out long *rangeEndOffset);</pre>
|
<pre style="margin-left: 0; padding-left: 0; border: 0; background-color: white;">
string getDefaultAttributes();</pre>
|}

== Parameters (for getTextAttributes/get_attributes/getAttributes) ==

; offset
: [in] the given offset

; rangeStartOffset
: [out] the start offset of the result range

; rangeEndOffset
: [out] the end offset of the result range

Ranges are not nested. They are consecutive, so that AT's always know when to ask for the next range. For example, for text 'abc<b>def</b>ghi', there are three ranges (0, 3), (3, 6) and (6, 9).

== Return Value for both methods ==

A collection of text attributes (the list of pairs consisted from name and value). All text attributes that apply to the current range are exposed, but in order to conserve the amount of data passed, most text attributes will have reasonable defaults and will not be exposed in the list when they are equal to the default. For example, if font-style is "normal" it will not be exposed in the return value. See the list of text attributes below to find the defaults.

The IA2 and ATK/AT-SPI return value is a single strange in the format name:value;name:value;name:value etc.

= Events =

When a certain text attribute is changed then the internal event 'EVENT_TEXT_ATTRIBUTE_CHANGED' should be fired.

In IA2, there is no data to specify what attribute changed, and for what offsets. Therefore, the AT must cache attributes of any objects that it will want to know about text attribute changes for. For example, it can cache the the text attribute ranges for the current text accessible, and compare the previous text attribute runs with the current text attribute runs.

Events will be fired for the topic object to which they apply, in order to avoid floods of too many events. For example, if someone selects all and then boldfaces the selection -- every object in the accessible tree is essentially getting an attribute change. We will reduce the number of events by only firing the text attribute change event on the root accessible for the change.

For Firefox 3, events will not be fired for style changes that are not caused by DOM changes. At the moment we are focused on the rich text editing use case. For rich text editing there will always be a DOM change.

= List of supported attributes =

== Gecko specific ==

{| summary="Gecko Specific Text Attributes" width="90%" border="1" cellspacing="1" cellpadding="1"
! Attribute name
! Attribute description
! Default value if attribute not exposed
|-
| invalid
| "spelling" if it is marked by the inline spell checker for being incorrectly spelled. Attribute not present in all other cases. Also can support "grammar" or "true" since aria-invalid can be used to mark up any span, and aria-invalid must map to this.
| Not misspelled or invalid in any way
|}

== Linux Foundation Proposed (ATK + IA2) ==

Note: the following characters in names and values need to be escaped with a backslash: backslash, colon, comma, equals, and semicolon.

{| summary="Proposed Text Attributes" width="90%" border="1" cellspacing="1" cellpadding="1"
! Attribute name
! Attribute description
! Default value if attribute not exposed
|-
| auto-generated
| "true" for list bullet/numbering text or layout-inserted text (such as via CSS pseudo styles :before or :after)
| false
|-
| background-color
| Background color as <code>rgb(<i>r</i>,<i>g</i>,<i>b</i>)</code> where <i>r</i>, <i>g</i> and <i>b</i> are 0-255
| transparent
|-
| color
| Foreground color as <code>rgb(<i>r</i>,<i>g</i>,<i>b</i>)</code> where <i>r</i>, <i>g</i> and <i>b</i> are 0-255
| rgb(0,0,0)
|-
| font-family
| The computed font name
| no default, always specified
|-
| font-size
| Font size in points
| no default, always specified
|-
| font-style
| italic (oblique not currently supported)
| normal
|-
| font-weight
| The computed font weight (100, 200, 300, 400, 500, 600, 700, 800, 900; normal = 400, bold = 700, bolder = 900)
| 500
|-
| language
| What language is this text in, e.g. en-US (do we want this or do we use IA2::locale and make sure each locale change gets separate accessible object?) We purposely call this language and not lang, to be in line with the [http://www.linuxfoundation.org/en/Accessibility/IAccessible2/TextAttributes IA2 text attributes spec].
| en-US
|-
| text-line-through-style
| solid (only exposed if if there is a line through)
| no line through
|-
| text-underline-style
| solid (only exposed if if there is an underline)
| no underline
|-
| text-align
| left/center/right/justify
| left
|-
| text-indent
| [#]mm where [#] is the number of millimeters (max precision = 1/100 of a millimeter). The text "mm" must come after the number.
| 0 = no indent
|-
| text-position (for sup/sub)
| super/sub (translate from values in vertical-align)
| none
|-
| writing-mode
| rl or lr (we don't support tb - top to bottom)
| lr
|}

== Currently unsupported ==

The following text attributes, which are in the [http://www.linux-foundation.org/en/Accessibility/IAccessible2/TextAttributes IAccessible2 text attribute specification], are not currently supported due to today's limitations of text formatting on the web:

* text-line-through-mode
* text-line-through-type
* text-underline-type
* text-underline-width
* text-underline-mode
* text-shadow

The following object attribute in IA2 is not supported, because we support it via text attributes in a different way:
* list (with sub-attributes style, level & prefix) -- the list bullet text is exposed via the accessible text interface, with the text attribute static=true

The following IA2 object attributes are not supported, but potentially could be if asked for. We may need them to fully support online word processors, but need to think about how to pass on the true intentions of the word processor at that place in the text. In fact, it is currently possible for the word processor to specify these on any object by prepending aria- to the object attribute name and simply insert the attribute on the appropriate element.
* line-height
* line-spacing
* text-align
* text-indent
* margin-left, margin-top, margin-right, margin-bottom: these object attributes are not supported, because the related browser CSS attributes have nothing to do with page margins as the IA2 object attributes do. In Mozilla the bounds of an object can be used to find where it is located.

= References =

* [http://www.linux-foundation.org/en/Accessibility/IAccessible2/TextAttributes IA2 Text Attributes] - IAccessible2 Text Attributes Documentation

Accessibility/ARIA Coordination

2008-09-09T09:11:22Z

Aaronlev: /* ARIA Community People */

= ARIA Community People =

The following is a list of people who want to collaborate on making ARIA better with free tools and resources.

{| summary="ARIA People" width="90%" border="1" cellspacing="1" cellpadding="1"
! Who
! Email
! What
! Where
|-
| Aaron Leventhal
| aleventh at us.ibm.com
| [http://developer.mozilla.org/en/ARIA_User_Agent_Implementors_Guide#Exposing_attributes_that_don.e2.80.99t_directly_map_to_accessibility_API_properties ARIA Implementors Guide], [http://www.w3.org/WAI/PF/Group/aria/ ARIA specification]
| Esslingen, Germany
|}

Accessibility

2008-09-09T09:10:56Z

Aaronlev: /* Mozilla Accessibility Wiki */

= Mozilla Accessibility Wiki =

* General
** [http://developer.mozilla.org/en/docs/Accessibility Development Center] - documentation on various accessibility initiatives, XUL authoring guidelines, ARIA, AT-SPI, web development and more
**[[Accessibility/Learning_Disabilities|Learning Disabilities]] - resources related to learning disabilities
** [[Accessibility/Testing|Testing Center]] - the latest on Mozilla accessibility testing, test plans, environments, top bugs, and more.

* Sections
**[[Mac:Accessibility| Mac Accessibility]] - home page of accessibility support on Mac.
** [[Accessibility/AT-Windows-API|Windows Accessibility]] - this FAQ explains how makers of Windows screen readers, voice dictation packages and magnification software can support Gecko-based software. The article is targeted on MSAA.
**[[Accessibility/XForms|XForms Accessibility]] - AT API support for XForms elements.

* Drafts
**[[Accessibility/Attributes|Attributes]] - proposed AT API attribute support.
**[[Accessibility/TextAttributes|Text Attributes]] - proposed AT API text attribute support.
**[[Accessibility/Datatypes|ARIA Type Attributes]] - proposed ARIA data type attributes to object attribute mapping
**[[Accessibility/AJAX:WAI_ARIA_Live_Region_Library|AJAX: WAI ARIA Live Region Library]]
**[[Accessibility/Accessible_Table_Implementation|Accessible Table Implementation]]
**[[Accessibility/IA2ToGecko|Mapping IAccessible2 to Gecko]]
**[[Accessibility/CustomWidgets|Custom widgets accessibility]]

* Project Coordination
**[[Accessibility/Firefox3|Firefox3]] - the list of meta bugs targeted to Firefox 3
**[[Accessibility/csun2008|CSUN 2008]] - Mozilla CSUN 2008 Activities
**[[Accessibility/Projects|Potential Accessibility Projects]]
**[[Accessibility/PlanMozilla2|Mozilla 2 accessibility plans]]
**[[Accessibility/ARIA_Coordination|ARIA coordination]]

Accessibility/ARIA Coordination

2008-09-09T09:10:14Z

Aaronlev: New page: = ARIA Community People = The following is a list of people who want to collaborate on making ARIA better with free tools and resources. {| summary="ARIA People" width="90%" border="1" c...

= ARIA Community People =

The following is a list of people who want to collaborate on making ARIA better with free tools and resources.

{| summary="ARIA People" width="90%" border="1" cellspacing="1" cellpadding="1"
! Who
! Email
! What
! Where
|-
| Aaron Leventhal
| aleventh at us.ibm.com
| [http://www.w3.org/WAI/PF/Group/aria/ ARIA Implementors Guide], [http://www.w3.org/WAI/PF/Group/aria/ ARIA specification]
| Esslingen, Germany
|}

Contributors/Germany Austria Switzerland

2008-08-04T19:17:39Z

Aaronlev:

Here is a list of people in Germany, Austria and Switzerland who work on Mozilla.

This idea was born at the 2008 summit, among the German-speakers there. But, definitely remove yourself from the list if you don't want to be on it.

The main IRC channel for development is #mozilla.de on irc.mozilla.org.

{| border="1" cellspacing="0" cellpadding="1"
! Name
! IRC
! Email
! City
! Role
! Notes
|-
| Christian Biesinger
| biesi
| cbiesinger__gmail.com
| Zürich
| Core developer
|
|-
| Carsten Book
| tomcat
| tomcat__@mozilla.com
| Pfronten
| QA Engineer
|
|-
| Patrick Brunschwig
|
|
|
| [http://enigmail.mozdev.org/home/index.php Enigmail]
|
|-
| Ben Bucksch
| benb
|
|
|
|
|-
| Simon Bünzli
|
| zeniko@gmail.com
|
| Front end developer
|
|-
| Martin Creutziger
| MMx
|
| Weinheim
| L10N contributor
|
|-
| Karsten Düsterloh
| mnyromyr
| [mailto:mnyromyr@tprac.de mnyromyr@tprac.de]
| Sprockhövel
| Developer: primarily [http://seamonkey-project.org SeaMonkey], [http://mnenhy.de Mnenhy], mail/news backend
|
|-
| Bruno Escherl
| aqualon
| [mailto:aqualon@aquachan.de aqualon@aquachan.de]
| Erlangen
| SeaMonkey dev (mostly mailnews part)
|
|-
| Christian Eyrich
|
|
|
|
|
|-
| Dão Gottwald
| dao
| dao__mozilla.com
|
| Front end developer
|
|-
| Axel Hecht
| pike
| axel__pike.org, l10n__mozilla.com
| Berlin
| L10n coordinator
| [http://blog.mozilla.com/axel/ blog]
|-
| Romi Harchiyanto
| romi
| romiharchiyanto__gmail.com
| Hamburg
| L10n-id
|
|-
| Alexander Ihrig
|
|
|
| TB L10N
|
|-
| Robert Kaiser
| kairo
|
|
|
|
|-
| Philip Kewisch
| Fallen
|
|
|
|
|-
| Aaron Leventhal
| aaronlev
| aaron__moonset.net
| Esslingen
| A11y developer
| In Germany since April, 2008. [http://accessgarage.wordpress.com/ Blog]
|-
| Cédric Menge
| chewey
| [mailto:mozwiki@chewey.de mozwiki@chewey.de]
| ~Karlsruhe
| Authoring recommended german Adblock Plus list; Enjoying the suite way of things; (very) occasional additional SM stuff; cook ;-)
| [http://chewey.de/mozilla/adblock-filterliste.html ABP stuff]
|-
| Bernd Mielke
|
|
|
| Layout
|
|-
| Wladimir Palant
|
|
|
| Adblock. Ist das nicht genug?
|
|-
| Simon Paquet
| sipaq
|
|
|
|
|-
| Martin Schröder
| mschroeder
|
|
|
|
|-
| Henrik Skupin
| whimboo
| mozilla__hskupin.info
| Karlsruhe
| QA, L10n
|
|-
| Markus Stange
| mstange
| mstange__themasta.com
| Mainz
| Mac dev
|
|-
| Abdulkadir Topal
| topal
| a.topal__gmail.com
| Duisburg
| L10n
|
|-
| Frank Wein
| mcsmurf
|
|
|
|
|-
| Frederic Wenzel
| fwenzel
|
|
|
|
|-
| Marco Zehe
| marcoz
| marco.zehe__googlemail.com
| Hamburg
| A11y QA
| [http://marcozehe.de/ blog]
|}

Contributors/Germany Austria Switzerland

2008-08-04T19:07:16Z

Aaronlev:

Here is a list of people in Germany, Austria and Switzerland who work on Mozilla.

This idea was born at the 2008 summit, among the German-speakers there. But, definitely remove yourself from the list if you don't want to be on it.

{| border="1" cellspacing="0" cellpadding="1"
! Name
! IRC
! Email
! City
! Role
! Notes
|-
| Christian Biesinger
| biesi
| cbiesinger__gmail.com
| Zürich
| Core developer
|
|-
| Carsten Book
| tomcat
| tomcat__@mozilla.com
| Pfronten
| QA Engineer
|
|-
| Patrick Brunschwig
|
|
|
| [http://enigmail.mozdev.org/home/index.php Enigmail]
|
|-
| Ben Bucksch
| benb
|
|
|
|
|-
| Simon Bünzli
|
| zeniko@gmail.com
|
| Front end developer
|
|-
| Martin Creutziger
| MMx
|
| Weinheim
| L10N contributor
|
|-
| Karsten Düsterloh
| mnyromyr
| [mailto:mnyromyr@tprac.de mnyromyr@tprac.de]
| Sprockhövel
| Developer: primarily [http://seamonkey-project.org SeaMonkey], [http://mnenhy.de Mnenhy], mail/news backend
|
|-
| Bruno Escherl
| aqualon
| [mailto:aqualon@aquachan.de aqualon@aquachan.de]
| Erlangen
| SeaMonkey dev (mostly mailnews part)
|
|-
| Christian Eyrich
|
|
|
|
|
|-
| Dão Gottwald
| dao
| dao__mozilla.com
|
| Front end developer
|
|-
| Axel Hecht
| pike
| axel__pike.org, l10n__mozilla.com
| Berlin
| L10n coordinator
| [http://blog.mozilla.com/axel/ blog]
|-
| Romi Harchiyanto
| romi
| romiharchiyanto__gmail.com
| Hamburg
| L10n-id
|
|-
| Alexander Ihrig
|
|
|
| TB L10N
|
|-
| Robert Kaiser
| kairo
|
|
|
|
|-
| Philip Kewisch
| Fallen
|
|
|
|
|-
| Aaron Leventhal
| aaronlev
| aaron__moonset.net
| Esslingen
| A11y developer
| In Germany since April, 2008. [http://accessgarage.wordpress.com/ Blog]
|-
| Cédric Menge
| chewey
| [mailto:mozwiki@chewey.de mozwiki@chewey.de]
| ~Karlsruhe
| Authoring recommended german Adblock Plus list; Enjoying the suite way of things; (very) occasional additional SM stuff; cook ;-)
| [http://chewey.de/mozilla/adblock-filterliste.html ABP stuff]
|-
| Bernd Mielke
|
|
|
| Layout
|
|-
| Wladimir Palant
|
|
|
| Adblock. Ist das nicht genug?
|
|-
| Simon Paquet
| sipaq
|
|
|
|
|-
| Martin Schröder
| mschroeder
|
|
|
|
|-
| Henrik Skupin
| whimboo
| mozilla__hskupin.info
| Karlsruhe
| QA, L10n
|
|-
| Markus Stange
| mstange
| mstange__themasta.com
| Mainz
| Mac dev
|
|-
| Abdulkadir Topal
| topal
| a.topal__gmail.com
| Duisburg
| L10n
|
|-
| Frank Wein
| mcsmurf
|
|
|
|
|-
| Frederic Wenzel
| fwenzel
|
|
|
|
|-
| Marco Zehe
| marcoz
| marco.zehe__googlemail.com
| Hamburg
| A11y QA
| [http://marcozehe.de/ blog]
|}

Accessibility/Captioning Work Plan

2008-08-04T11:38:54Z

Aaronlev:

To do:
# Separate into phase 1 and phase 2. How should we split? Captioning vs. audio description? Or, make technical choices in phase 1 and create test cases/docs etc. in 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
# Add points for audio description
# Describe the true complexity of the problem.
# Question: is this really a grant to fix captioning in Ogg? If other formats already have captioning built-in, what else might need to be done? How does this relate to the greater HTML 5 effort?

= Background =

There is both a container and a codec involved for each video format. For a given container, you need to have a defined (and supported by tools and other video players for network effects) mapping for muxing a giving captioning format into the container. So the video codec rules. The container depends on what's conventional for the video codec, and the choice of captioning format depends on what's conventional for the container. In theory, given a muxing rule, you can put any video codec and any captiong format in any container, but in practice, video codec tends to have a conventional native container, so the video codec dictates the container and then different containers have different conventional timed text formats and the timed text formats might not have muxing rules for non-native containers. Example: Ogg and MP4 are containers, whereas Theora and H.264 are codecs. Gstreamer and QuickTime are both timed media frameworks, which each can play various other container/codec combinations (?). Ogg, Theora and CMML are a natural match. MP4, H.264 and 3GPP TT are a natural match. While technically, you *could* define a way to put 3GPP TT inside Ogg, the disadvantage to doing this is blah.

{| summary="Map of video technology for the web" border="1"
! Framework
! Container
! Codecs
! Authoring tools
! Natural captioning format
|-
| liboggplay
| Ogg
|
* Theora (video)
* Vorbis (audio)
|
| CMML
|-
|
| MP4
| H.264
|
| 3GPP Timed Text
|-
| Flash plugin
| .flv
|
|
|
|-
| GStreamer
|
|
|
|
|-
| QuickTime
|
|
|
|
|-
| DirectShow
|
|
|
|
|}

Note: Subrip is external to the video container and can be used with any format. The main known disadvantage of this is blah, blah. It would make sense to use this if blah.

= Work plan for Captioning =

# Determine which captioning format should be supported in Mozilla for the natively-supported Ogg video. This needs to take into account the extremely complex map of video formats and players today (see above).
# 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. [[User:Hsivonen|Hsivonen]] 09:06, 4 August 2008 (UTC)) [[User:aaronlev|aaronlev]] Henri also mentioned that potential legal issues could affect technical issues, but we aren't sure. It would be good if WGBH had some background to help understand this as well while devising a captioning solution.
##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)) [[User:aaronlev|aaronlev]] I'm not sure -- there are some higher level things such as embedding of a musical note graphic to indicate music. I believe that captioning is moving toward expressing more complex background information.
# 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 the solution is compatible with 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.
# Ensure the solition incorporates the expressed needs and preferences of Internet-based media users with sensory disabilities. (( Aaron: what are these? Can we express these up front? WGBH must already know this info, e.g. why would it change based on internet vs. brodcast? ))
# Ensure all solutions, documentation and tests developed are friendly to open source contributors and clean of known IP conflicts
# Participate in the relevant deliberations, meetings, standards development activities and proposed work products of HTML 5 WG.
# 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 a complete set of open-licensed documentation and test cases for developers and content creators. In general, reach out to developers implementing captioning solutions for the web and 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 are well-understood.
# 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.

= Work Plan for Audio Description =

TBD

= Success Criteria =
# A complete set of documentation and test cases for captioning and audio descriotion, without unnecessary IP restrictions, is available
# Mozilla and should implement the proposed solution for both captioning and audio description, in a manner which maximizes usability. For example, there should be a consistent UI for turning captions on or off, no matter what the video format being used is.
# Authoring tools are available which support the solutions
# At least one mainstream source of video content on the web (e.g. wikimedia) has some content which supports the proposed solution for captioning and audio description

Accessibility/Captioning Work Plan

2008-08-04T11:37:14Z

Aaronlev:

To do:
# Separate into phase 1 and phase 2. How should we split? Captioning vs. audio description? Or, make technical choices in phase 1 and create test cases/docs etc. in 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
# Add points for audio description
# Describe the true complexity of the problem.

= Background =

There is both a container and a codec involved for each video format. For a given container, you need to have a defined (and supported by tools and other video players for network effects) mapping for muxing a giving captioning format into the container. So the video codec rules. The container depends on what's conventional for the video codec, and the choice of captioning format depends on what's conventional for the container. In theory, given a muxing rule, you can put any video codec and any captiong format in any container, but in practice, video codec tends to have a conventional native container, so the video codec dictates the container and then different containers have different conventional timed text formats and the timed text formats might not have muxing rules for non-native containers. Example: Ogg and MP4 are containers, whereas Theora and H.264 are codecs. Gstreamer and QuickTime are both timed media frameworks, which each can play various other container/codec combinations (?). Ogg, Theora and CMML are a natural match. MP4, H.264 and 3GPP TT are a natural match. While technically, you *could* define a way to put 3GPP TT inside Ogg, the disadvantage to doing this is blah.

{| summary="Map of video technology for the web" border="1"
! Framework
! Container
! Codecs
! Authoring tools
! Natural captioning format
|-
| liboggplay
| Ogg
|
* Theora (video)
* Vorbis (audio)
|
| CMML
|-
|
| MP4
| H.264
|
| 3GPP Timed Text
|-
| Flash plugin
| .flv
|
|
|
|-
| GStreamer
|
|
|
|
|-
| QuickTime
|
|
|
|
|-
| DirectShow
|
|
|
|
|}

Note: Subrip is external to the video container and can be used with any format. The main known disadvantage of this is blah, blah. It would make sense to use this if blah.

= Work plan for Captioning =

# Determine which captioning format should be supported in Mozilla for the natively-supported Ogg video. This needs to take into account the extremely complex map of video formats and players today (see above).
# 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. [[User:Hsivonen|Hsivonen]] 09:06, 4 August 2008 (UTC)) [[User:aaronlev|aaronlev]] Henri also mentioned that potential legal issues could affect technical issues, but we aren't sure. It would be good if WGBH had some background to help understand this as well while devising a captioning solution.
##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)) [[User:aaronlev|aaronlev]] I'm not sure -- there are some higher level things such as embedding of a musical note graphic to indicate music. I believe that captioning is moving toward expressing more complex background information.
# 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 the solution is compatible with 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.
# Ensure the solition incorporates the expressed needs and preferences of Internet-based media users with sensory disabilities. (( Aaron: what are these? Can we express these up front? WGBH must already know this info, e.g. why would it change based on internet vs. brodcast? ))
# Ensure all solutions, documentation and tests developed are friendly to open source contributors and clean of known IP conflicts
# Participate in the relevant deliberations, meetings, standards development activities and proposed work products of HTML 5 WG.
# 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 a complete set of open-licensed documentation and test cases for developers and content creators. In general, reach out to developers implementing captioning solutions for the web and 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 are well-understood.
# 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.

= Work Plan for Audio Description =

TBD

= Success Criteria =
# A complete set of documentation and test cases for captioning and audio descriotion, without unnecessary IP restrictions, is available
# Mozilla and should implement the proposed solution for both captioning and audio description, in a manner which maximizes usability. For example, there should be a consistent UI for turning captions on or off, no matter what the video format being used is.
# Authoring tools are available which support the solutions
# At least one mainstream source of video content on the web (e.g. wikimedia) has some content which supports the proposed solution for captioning and audio description

Accessibility/Captioning Work Plan

2008-08-04T10:25:09Z

Aaronlev: /* Background */

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
# Add points for audio description
# Describe the true complexity of the problem.

= Background =

There is both a container and a codec involved for each video format. For a given container, you need to have a defined (and supported by tools and other video players for network effects) mapping for muxing a giving captioning format into the container. So the video codec rules. The container depends on what's conventional for the video codec, and the choice of captioning format depends on what's conventional for the container. In theory, given a muxing rule, you can put any video codec and any captiong format in any container, but in practice, video codec tends to have a conventional native container, so the video codec dictates the container and then different containers have different conventional timed text formats and the timed text formats might not have muxing rules for non-native containers. Example: Ogg and MP4 are containers, whereas Theora and H.264 are codecs. Gstreamer and QuickTime are both timed media frameworks, which each can play various other container/codec combinations (?). Ogg, Theora and CMML are a natural match. MP4, H.264 and 3GPP TT are a natural match. While technically, you *could* define a way to put 3GPP TT inside Ogg, the disadvantage to doing this is blah.

{| summary="Map of video technology for the web" border="1"
! Framework
! Container
! Codecs
! Authoring tools
! Natural captioning format
|-
| liboggplay
| Ogg
|
* Theora (video)
* Vorbis (audio)
|
| CMML
|-
|
| MP4
| H.264
|
| 3GPP Timed Text
|-
| Flash plugin
| .flv
|
|
|
|-
| GStreamer
|
|
|
|
|-
| QuickTime
|
|
|
|
|-
| DirectShow
|
|
|
|
|}

Note: Subrip is external to the video container and can be used with any format. The main known disadvantage of this is blah, blah. It would make sense to use this if blah.

= Work plan for Captioning =

# Determine which captioning format should be supported in Mozilla for the natively-supported Ogg video. This needs to take into account the extremely complex map of video formats and players today (see above).
# 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. [[User:Hsivonen|Hsivonen]] 09:06, 4 August 2008 (UTC)) [[User:aaronlev|aaronlev]] Henri also mentioned that potential legal issues could affect technical issues, but we aren't sure. It would be good if WGBH had some background to help understand this as well while devising a captioning solution.
##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)) [[User:aaronlev|aaronlev]] I'm not sure -- there are some higher level things such as embedding of a musical note graphic to indicate music. I believe that captioning is moving toward expressing more complex background information.
# 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 the solution is compatible with 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.
# Ensure the solition incorporates the expressed needs and preferences of Internet-based media users with sensory disabilities. (( Aaron: what are these? Can we express these up front? WGBH must already know this info, e.g. why would it change based on internet vs. brodcast? ))
# Ensure all solutions, documentation and tests developed are friendly to open source contributors and clean of known IP conflicts
# Participate in the relevant deliberations, meetings, standards development activities and proposed work products of HTML 5 WG.
# 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 a complete set of open-licensed documentation and test cases for developers and content creators. In general, reach out to developers implementing captioning solutions for the web and 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 are well-understood.
# 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.

= Work Plan for Audio Description =

TBD

= Success Criteria =
# A complete set of documentation and test cases for captioning and audio descriotion, without unnecessary IP restrictions, is available
# Mozilla and should implement the proposed solution for both captioning and audio description, in a manner which maximizes usability. For example, there should be a consistent UI for turning captions on or off, no matter what the video format being used is.
# Authoring tools are available which support the solutions
# At least one mainstream source of video content on the web (e.g. wikimedia) has some content which supports the proposed solution for captioning and audio description

Accessibility/Captioning Work Plan

2008-08-04T10:23:30Z

Aaronlev:

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
# Add points for audio description
# Describe the true complexity of the problem.

= Background =

There is both a container and a codec involved for each video format. For a given container, you need to have a defined (and supported by tools and other video players for network effects) mapping for muxing a giving captioning format into the container. So the video codec rules. The container depends on what's conventional for the video codec, and the choice of captioning format depends on what's conventional for the container. In theory, given a muxing rule, you can put any video codec and any captiong format in any container, but in practice, video codec tends to have a conventional native container, so the video codec dictates the container and then different containers have different conventional timed text formats and the timed text formats might not have muxing rules for non-native containers. Example: Ogg and MP4 are containers, whereas Theora and H.264 are codecs. Gstreamer and QuickTime are both timed media frameworks, which each can play various other container/codec combinations (?). Ogg, Theora and CMML are a natural match. MP4, H.264 and 3GPP TT are a natural match. While technically, you *could* define a way to put 3GPP TT inside Ogg, the disadvantage to doing this is blah.

{|
! Framework
! Container
! Codecs
! Authoring tools
! Natural captioning format
|-
| liboggplay
| Ogg
|
* Theora (video)
* Vorbis (audio)
|
CMML
|-
|
| MP4
| H.264
|
| 3GPP Timed Text
|-
| GStreamer
|
|
|
|
|-
| QuickTime
|
|
|
|
|-
| DirectShow
|
|
|
|
|}

Note: Subrip is external to the video container and can be used with any format. The main known disadvantage of this is blah, blah. It would make sense to use this if blah.

= Work plan for Captioning =

# Determine which captioning format should be supported in Mozilla for the natively-supported Ogg video. This needs to take into account the extremely complex map of video formats and players today (see above).
# 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. [[User:Hsivonen|Hsivonen]] 09:06, 4 August 2008 (UTC)) [[User:aaronlev|aaronlev]] Henri also mentioned that potential legal issues could affect technical issues, but we aren't sure. It would be good if WGBH had some background to help understand this as well while devising a captioning solution.
##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)) [[User:aaronlev|aaronlev]] I'm not sure -- there are some higher level things such as embedding of a musical note graphic to indicate music. I believe that captioning is moving toward expressing more complex background information.
# 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 the solution is compatible with 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.
# Ensure the solition incorporates the expressed needs and preferences of Internet-based media users with sensory disabilities. (( Aaron: what are these? Can we express these up front? WGBH must already know this info, e.g. why would it change based on internet vs. brodcast? ))
# Ensure all solutions, documentation and tests developed are friendly to open source contributors and clean of known IP conflicts
# Participate in the relevant deliberations, meetings, standards development activities and proposed work products of HTML 5 WG.
# 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 a complete set of open-licensed documentation and test cases for developers and content creators. In general, reach out to developers implementing captioning solutions for the web and 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 are well-understood.
# 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.

= Work Plan for Audio Description =

TBD

= Success Criteria =
# A complete set of documentation and test cases for captioning and audio descriotion, without unnecessary IP restrictions, is available
# Mozilla and should implement the proposed solution for both captioning and audio description, in a manner which maximizes usability. For example, there should be a consistent UI for turning captions on or off, no matter what the video format being used is.
# Authoring tools are available which support the solutions
# At least one mainstream source of video content on the web (e.g. wikimedia) has some content which supports the proposed solution for captioning and audio description

Accessibility/Captioning Work Plan

2008-08-04T10:18:21Z

Aaronlev: /* Success Criteria */

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
# Add points for audio description
# Describe the true complexity of the problem.

= Work plan for Captioning =

# Determine which captioning format should be supported in Mozilla for the natively-supported Ogg video. This needs to take into account the extremely complex map of video formats and players today. There is both a container and a codec involved for each video format. For a given container, you need to have a defined (and supported by tools and other video players for network effects) mapping for muxing a giving captioning format into the container. So the video codec rules. The container depends on what's conventional for the video codec, and the choice of captioning format depends on what's conventional for the container. In theory, given a muxing rule, you can put any video codec and any captiong format in any container, but in practice, video codec tends to have a conventional native container, so the video codec dictates the container and then different containers have different conventional timed text formats and the timed text formats might not have muxing rules for non-native containers. Example: Ogg and MP4 are containers, whereas Theora and H.264 are codecs. Gstreamer and QuickTime are both timed media frameworks, which each can play various other container/codec combinations (?). Ogg, Theora and CMML are a natural match. MP4, H.264 and 3GPP TT are a natural match. While technically, you *could* define a way to put 3GPP TT inside Ogg, the disadvantage to doing this is blah.
# 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. [[User:Hsivonen|Hsivonen]] 09:06, 4 August 2008 (UTC)) [[User:aaronlev|aaronlev]] Henri also mentioned that potential legal issues could affect technical issues, but we aren't sure. It would be good if WGBH had some background to help understand this as well while devising a captioning solution.
##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)) [[User:aaronlev|aaronlev]] I'm not sure -- there are some higher level things such as embedding of a musical note graphic to indicate music. I believe that captioning is moving toward expressing more complex background information.
# 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 the solution is compatible with 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.
# Ensure the solition incorporates the expressed needs and preferences of Internet-based media users with sensory disabilities. (( Aaron: what are these? Can we express these up front? WGBH must already know this info, e.g. why would it change based on internet vs. brodcast? ))
# Ensure all solutions, documentation and tests developed are friendly to open source contributors and clean of known IP conflicts
# Participate in the relevant deliberations, meetings, standards development activities and proposed work products of HTML 5 WG.
# 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 a complete set of open-licensed documentation and test cases for developers and content creators. In general, reach out to developers implementing captioning solutions for the web and 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 are well-understood.
# 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.

= Work Plan for Audio Description =

TBD

= Success Criteria =
# A complete set of documentation and test cases for captioning and audio descriotion, without unnecessary IP restrictions, is available
# Mozilla and should implement the proposed solution for both captioning and audio description, in a manner which maximizes usability. For example, there should be a consistent UI for turning captions on or off, no matter what the video format being used is.
# Authoring tools are available which support the solutions
# At least one mainstream source of video content on the web (e.g. wikimedia) has some content which supports the proposed solution for captioning and audio description

Accessibility/Captioning Work Plan

2008-08-04T10:17:27Z

Aaronlev: /* Success Criteria */

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
# Add points for audio description
# Describe the true complexity of the problem.

= Work plan for Captioning =

# Determine which captioning format should be supported in Mozilla for the natively-supported Ogg video. This needs to take into account the extremely complex map of video formats and players today. There is both a container and a codec involved for each video format. For a given container, you need to have a defined (and supported by tools and other video players for network effects) mapping for muxing a giving captioning format into the container. So the video codec rules. The container depends on what's conventional for the video codec, and the choice of captioning format depends on what's conventional for the container. In theory, given a muxing rule, you can put any video codec and any captiong format in any container, but in practice, video codec tends to have a conventional native container, so the video codec dictates the container and then different containers have different conventional timed text formats and the timed text formats might not have muxing rules for non-native containers. Example: Ogg and MP4 are containers, whereas Theora and H.264 are codecs. Gstreamer and QuickTime are both timed media frameworks, which each can play various other container/codec combinations (?). Ogg, Theora and CMML are a natural match. MP4, H.264 and 3GPP TT are a natural match. While technically, you *could* define a way to put 3GPP TT inside Ogg, the disadvantage to doing this is blah.
# 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. [[User:Hsivonen|Hsivonen]] 09:06, 4 August 2008 (UTC)) [[User:aaronlev|aaronlev]] Henri also mentioned that potential legal issues could affect technical issues, but we aren't sure. It would be good if WGBH had some background to help understand this as well while devising a captioning solution.
##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)) [[User:aaronlev|aaronlev]] I'm not sure -- there are some higher level things such as embedding of a musical note graphic to indicate music. I believe that captioning is moving toward expressing more complex background information.
# 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 the solution is compatible with 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.
# Ensure the solition incorporates the expressed needs and preferences of Internet-based media users with sensory disabilities. (( Aaron: what are these? Can we express these up front? WGBH must already know this info, e.g. why would it change based on internet vs. brodcast? ))
# Ensure all solutions, documentation and tests developed are friendly to open source contributors and clean of known IP conflicts
# Participate in the relevant deliberations, meetings, standards development activities and proposed work products of HTML 5 WG.
# 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 a complete set of open-licensed documentation and test cases for developers and content creators. In general, reach out to developers implementing captioning solutions for the web and 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 are well-understood.
# 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.

= Work Plan for Audio Description =

TBD

= Success Criteria =
# A complete set of documentation and test cases for captioning and audio descriotion, without unnecessary IP restrictions, is available
# Mozilla and other browser implementations implement the proposed solution for both captioning and audio description. In Mozilla, there should be a consistent UI for turning captions on or off, no matter what the video format being used is.
# Authoring tools are available which support the solutions
# At least one mainstream source of video content on the web (e.g. wikimedia) has some content which supports the proposed solution for captioning and audio description

Accessibility/Captioning Work Plan

2008-08-04T10:08:16Z

Aaronlev: /* Success Criteria */

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
# Add points for audio description
# Describe the true complexity of the problem.

= Work plan for Captioning =

# Determine which captioning format should be supported in Mozilla for the natively-supported Ogg video. This needs to take into account the extremely complex map of video formats and players today. There is both a container and a codec involved for each video format. For a given container, you need to have a defined (and supported by tools and other video players for network effects) mapping for muxing a giving captioning format into the container. So the video codec rules. The container depends on what's conventional for the video codec, and the choice of captioning format depends on what's conventional for the container. In theory, given a muxing rule, you can put any video codec and any captiong format in any container, but in practice, video codec tends to have a conventional native container, so the video codec dictates the container and then different containers have different conventional timed text formats and the timed text formats might not have muxing rules for non-native containers. Example: Ogg and MP4 are containers, whereas Theora and H.264 are codecs. Gstreamer and QuickTime are both timed media frameworks, which each can play various other container/codec combinations (?). Ogg, Theora and CMML are a natural match. MP4, H.264 and 3GPP TT are a natural match. While technically, you *could* define a way to put 3GPP TT inside Ogg, the disadvantage to doing this is blah.
# 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. [[User:Hsivonen|Hsivonen]] 09:06, 4 August 2008 (UTC)) [[User:aaronlev|aaronlev]] Henri also mentioned that potential legal issues could affect technical issues, but we aren't sure. It would be good if WGBH had some background to help understand this as well while devising a captioning solution.
##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)) [[User:aaronlev|aaronlev]] I'm not sure -- there are some higher level things such as embedding of a musical note graphic to indicate music. I believe that captioning is moving toward expressing more complex background information.
# 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 the solution is compatible with 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.
# Ensure the solition incorporates the expressed needs and preferences of Internet-based media users with sensory disabilities. (( Aaron: what are these? Can we express these up front? WGBH must already know this info, e.g. why would it change based on internet vs. brodcast? ))
# Ensure all solutions, documentation and tests developed are friendly to open source contributors and clean of known IP conflicts
# Participate in the relevant deliberations, meetings, standards development activities and proposed work products of HTML 5 WG.
# 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 a complete set of open-licensed documentation and test cases for developers and content creators. In general, reach out to developers implementing captioning solutions for the web and 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 are well-understood.
# 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.

= Work Plan for Audio Description =

TBD

= Success Criteria =
# A complete set of documentation and test cases for captioning and audio descriotion, without unnecessary IP restrictions, is available
# Mozilla and other browser implementations implement the proposed solution for both captioning and audio description
# Authoring tools are available which support the solutions
# At least one mainstream source of video content on the web (e.g. wikimedia) has some content which supports the proposed solution for captioning and audio description

Accessibility/Captioning Work Plan

2008-08-04T10:06:48Z

Aaronlev: /* Work plan */

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
# Add points for audio description
# Describe the true complexity of the problem.

= Work plan for Captioning =

# Determine which captioning format should be supported in Mozilla for the natively-supported Ogg video. This needs to take into account the extremely complex map of video formats and players today. There is both a container and a codec involved for each video format. For a given container, you need to have a defined (and supported by tools and other video players for network effects) mapping for muxing a giving captioning format into the container. So the video codec rules. The container depends on what's conventional for the video codec, and the choice of captioning format depends on what's conventional for the container. In theory, given a muxing rule, you can put any video codec and any captiong format in any container, but in practice, video codec tends to have a conventional native container, so the video codec dictates the container and then different containers have different conventional timed text formats and the timed text formats might not have muxing rules for non-native containers. Example: Ogg and MP4 are containers, whereas Theora and H.264 are codecs. Gstreamer and QuickTime are both timed media frameworks, which each can play various other container/codec combinations (?). Ogg, Theora and CMML are a natural match. MP4, H.264 and 3GPP TT are a natural match. While technically, you *could* define a way to put 3GPP TT inside Ogg, the disadvantage to doing this is blah.
# 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. [[User:Hsivonen|Hsivonen]] 09:06, 4 August 2008 (UTC)) [[User:aaronlev|aaronlev]] Henri also mentioned that potential legal issues could affect technical issues, but we aren't sure. It would be good if WGBH had some background to help understand this as well while devising a captioning solution.
##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)) [[User:aaronlev|aaronlev]] I'm not sure -- there are some higher level things such as embedding of a musical note graphic to indicate music. I believe that captioning is moving toward expressing more complex background information.
# 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 the solution is compatible with 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.
# Ensure the solition incorporates the expressed needs and preferences of Internet-based media users with sensory disabilities. (( Aaron: what are these? Can we express these up front? WGBH must already know this info, e.g. why would it change based on internet vs. brodcast? ))
# Ensure all solutions, documentation and tests developed are friendly to open source contributors and clean of known IP conflicts
# Participate in the relevant deliberations, meetings, standards development activities and proposed work products of HTML 5 WG.
# 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 a complete set of open-licensed documentation and test cases for developers and content creators. In general, reach out to developers implementing captioning solutions for the web and 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 are well-understood.
# 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.

= Work Plan for Audio Description =

TBD

= Success Criteria =
# A complete set of documentation and test cases without unnecessary IP restrictions is available
# Mozilla and other browser implementations implement the proposed solution for captioning and audio description
# Authoring tools are supported
# At least one mainstream source of video content on the web (e.g. wikimedia) supports the proposed solution

Accessibility/Captioning Work Plan

2008-08-04T10:05:49Z

Aaronlev:

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
# Add points for audio description
# Describe the true complexity of the problem.

= Work plan =

# Determine which captioning format should be supported in Mozilla for the natively-supported Ogg video. This needs to take into account the extremely complex map of video formats and players today. There is both a container and a codec involved for each video format. For a given container, you need to have a defined (and supported by tools and other video players for network effects) mapping for muxing a giving captioning format into the container. So the video codec rules. The container depends on what's conventional for the video codec, and the choice of captioning format depends on what's conventional for the container. In theory, given a muxing rule, you can put any video codec and any captiong format in any container, but in practice, video codec tends to have a conventional native container, so the video codec dictates the container and then different containers have different conventional timed text formats and the timed text formats might not have muxing rules for non-native containers. Example: Ogg and MP4 are containers, whereas Theora and H.264 are codecs. Gstreamer and QuickTime are both timed media frameworks, which each can play various other container/codec combinations (?). Ogg, Theora and CMML are a natural match. MP4, H.264 and 3GPP TT are a natural match. While technically, you *could* define a way to put 3GPP TT inside Ogg, the disadvantage to doing this is blah.
# 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. [[User:Hsivonen|Hsivonen]] 09:06, 4 August 2008 (UTC)) [[User:aaronlev|aaronlev]] Henri also mentioned that potential legal issues could affect technical issues, but we aren't sure. It would be good if WGBH had some background to help understand this as well while devising a captioning solution.
##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)) [[User:aaronlev|aaronlev]] I'm not sure -- there are some higher level things such as embedding of a musical note graphic to indicate music. I believe that captioning is moving toward expressing more complex background information.
# 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 the solution is compatible with 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.
# Ensure the solition incorporates the expressed needs and preferences of Internet-based media users with sensory disabilities. (( Aaron: what are these? Can we express these up front? WGBH must already know this info, e.g. why would it change based on internet vs. brodcast? ))
# Ensure all solutions, documentation and tests developed are friendly to open source contributors and clean of known IP conflicts
# Participate in the relevant deliberations, meetings, standards development activities and proposed work products of HTML 5 WG.
# 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 a complete set of open-licensed documentation and test cases for developers and content creators. In general, reach out to developers implementing captioning solutions for the web and 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 are well-understood.
# 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.

= Success Criteria =
# A complete set of documentation and test cases without unnecessary IP restrictions is available
# Mozilla and other browser implementations implement the proposed solution for captioning and audio description
# Authoring tools are supported
# At least one mainstream source of video content on the web (e.g. wikimedia) supports the proposed solution

Accessibility/Captioning Work Plan

2008-08-04T10:05:26Z

Aaronlev: /* Success Criteria */

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
# Add points for audio description
# Describe the true complexity of the problem.

= Work plan =

# Determine which captioning format should be supported in Mozilla for the natively-supported Ogg video. This needs to take into account the extremely complex map of video formats and players today. There is both a container and a codec involved for each video format. For a given container, you need to have a defined (and supported by tools and other video players for network effects) mapping for muxing a giving captioning format into the container. So the video codec rules. The container depends on what's conventional for the video codec, and the choice of captioning format depends on what's conventional for the container. In theory, given a muxing rule, you can put any video codec and any captiong format in any container, but in practice, video codec tends to have a conventional native container, so the video codec dictates the container and then different containers have different conventional timed text formats and the timed text formats might not have muxing rules for non-native containers. Example: Ogg and MP4 are containers, whereas Theora and H.264 are codecs. Gstreamer and QuickTime are both timed media frameworks, which each can play various other container/codec combinations (?). Ogg, Theora and CMML are a natural match. MP4, H.264 and 3GPP TT are a natural match. While technically, you *could* define a way to put 3GPP TT inside Ogg, the disadvantage to doing this is blah.
# 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. [[User:Hsivonen|Hsivonen]] 09:06, 4 August 2008 (UTC)) [[User:aaronlev|aaronlev]] Henri also mentioned that potential legal issues could affect technical issues, but we aren't sure. It would be good if WGBH had some background to help understand this as well while devising a captioning solution.
##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)) [[User:aaronlev|aaronlev]] I'm not sure -- there are some higher level things such as embedding of a musical note graphic to indicate music. I believe that captioning is moving toward expressing more complex background information.
# 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 the solution is compatible with 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.
# Ensure the solition incorporates the expressed needs and preferences of Internet-based media users with sensory disabilities. (( Aaron: what are these? Can we express these up front? WGBH must already know this info, e.g. why would it change based on internet vs. brodcast? ))
# Ensure all solutions, documentation and tests developed are friendly to open source contributors and clean of known IP conflicts
# Participate in the relevant deliberations, meetings, standards development activities and proposed work products of HTML 5 WG.
# 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 a complete set of open-licensed documentation and test cases for developers and content creators. In general, reach out to developers implementing captioning solutions for the web and 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 are well-understood.
# 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.

= Success Criteria =
# A complete set of documentation and test cases without unnecessary IP restrictions is available
# Mozilla and other browser implementations implement the proposed solution for captioning and audio description
# Authoring tools are supported
# At least one major source of video content on the web supports the proposed solution

Accessibility/Captioning Work Plan

2008-08-04T10:03:04Z

Aaronlev: /* Measurements of Success (previous list) */

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
# Add points for audio description
# Describe the true complexity of the problem.

= Work plan =

# Determine which captioning format should be supported in Mozilla for the natively-supported Ogg video. This needs to take into account the extremely complex map of video formats and players today. There is both a container and a codec involved for each video format. For a given container, you need to have a defined (and supported by tools and other video players for network effects) mapping for muxing a giving captioning format into the container. So the video codec rules. The container depends on what's conventional for the video codec, and the choice of captioning format depends on what's conventional for the container. In theory, given a muxing rule, you can put any video codec and any captiong format in any container, but in practice, video codec tends to have a conventional native container, so the video codec dictates the container and then different containers have different conventional timed text formats and the timed text formats might not have muxing rules for non-native containers. Example: Ogg and MP4 are containers, whereas Theora and H.264 are codecs. Gstreamer and QuickTime are both timed media frameworks, which each can play various other container/codec combinations (?). Ogg, Theora and CMML are a natural match. MP4, H.264 and 3GPP TT are a natural match. While technically, you *could* define a way to put 3GPP TT inside Ogg, the disadvantage to doing this is blah.
# 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. [[User:Hsivonen|Hsivonen]] 09:06, 4 August 2008 (UTC)) [[User:aaronlev|aaronlev]] Henri also mentioned that potential legal issues could affect technical issues, but we aren't sure. It would be good if WGBH had some background to help understand this as well while devising a captioning solution.
##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)) [[User:aaronlev|aaronlev]] I'm not sure -- there are some higher level things such as embedding of a musical note graphic to indicate music. I believe that captioning is moving toward expressing more complex background information.
# 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 the solution is compatible with 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.
# Ensure the solition incorporates the expressed needs and preferences of Internet-based media users with sensory disabilities. (( Aaron: what are these? Can we express these up front? WGBH must already know this info, e.g. why would it change based on internet vs. brodcast? ))
# Ensure all solutions, documentation and tests developed are friendly to open source contributors and clean of known IP conflicts
# Participate in the relevant deliberations, meetings, standards development activities and proposed work products of HTML 5 WG.
# 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 a complete set of open-licensed documentation and test cases for developers and content creators. In general, reach out to developers implementing captioning solutions for the web and 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 are well-understood.
# 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.

= Success Criteria =
Mozilla and other browser implementations implement the proposed solution for captioning and audio description

Accessibility/Captioning Work Plan

2008-08-04T10:00:25Z

Aaronlev: /* Work plan */

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
# Add points for audio description
# Describe the true complexity of the problem.

= Work plan =

# Determine which captioning format should be supported in Mozilla for the natively-supported Ogg video. This needs to take into account the extremely complex map of video formats and players today. There is both a container and a codec involved for each video format. For a given container, you need to have a defined (and supported by tools and other video players for network effects) mapping for muxing a giving captioning format into the container. So the video codec rules. The container depends on what's conventional for the video codec, and the choice of captioning format depends on what's conventional for the container. In theory, given a muxing rule, you can put any video codec and any captiong format in any container, but in practice, video codec tends to have a conventional native container, so the video codec dictates the container and then different containers have different conventional timed text formats and the timed text formats might not have muxing rules for non-native containers. Example: Ogg and MP4 are containers, whereas Theora and H.264 are codecs. Gstreamer and QuickTime are both timed media frameworks, which each can play various other container/codec combinations (?). Ogg, Theora and CMML are a natural match. MP4, H.264 and 3GPP TT are a natural match. While technically, you *could* define a way to put 3GPP TT inside Ogg, the disadvantage to doing this is blah.
# 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. [[User:Hsivonen|Hsivonen]] 09:06, 4 August 2008 (UTC)) [[User:aaronlev|aaronlev]] Henri also mentioned that potential legal issues could affect technical issues, but we aren't sure. It would be good if WGBH had some background to help understand this as well while devising a captioning solution.
##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)) [[User:aaronlev|aaronlev]] I'm not sure -- there are some higher level things such as embedding of a musical note graphic to indicate music. I believe that captioning is moving toward expressing more complex background information.
# 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 the solution is compatible with 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.
# Ensure the solition incorporates the expressed needs and preferences of Internet-based media users with sensory disabilities. (( Aaron: what are these? Can we express these up front? WGBH must already know this info, e.g. why would it change based on internet vs. brodcast? ))
# Ensure all solutions, documentation and tests developed are friendly to open source contributors and clean of known IP conflicts
# Participate in the relevant deliberations, meetings, standards development activities and proposed work products of HTML 5 WG.
# 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 a complete set of open-licensed documentation and test cases for developers and content creators. In general, reach out to developers implementing captioning solutions for the web and 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 are well-understood.
# 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.

= 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.

Accessibility/Captioning Work Plan

2008-08-04T09:59:59Z

Aaronlev: /* Work plan */

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
# Add points for audio description
# Describe the true complexity of the problem.

= Work plan =

# Determine which captioning format should be supported in Mozilla for the natively-supported Ogg video. This needs to take into account the extremely complex map of video formats and players today. There is both a container and a codec involved for each video format. For a given container, you need to have a defined (and supported by tools and other video players for network effects) mapping for muxing a giving captioning format into the container. So the video codec rules. The container depends on what's conventional for the video codec, and the choice of captioning format depends on what's conventional for the container. In theory, given a muxing rule, you can put any video codec and any captiong format in any container, but in practice, video codec tends to have a conventional native container, so the video codec dictates the container and then different containers have different conventional timed text formats and the timed text formats might not have muxing rules for non-native containers. Example: Ogg and MP4 are containers, whereas Theora and H.264 are codecs. Gstreamer and QuickTime are both timed media frameworks, which each can play various other container/codec combinations (?). Ogg, Theora and CMML are a natural match. MP4, H.264 and 3GPP TT are a natural match. While technically, you *could* define a way to put 3GPP TT inside Ogg, the disadvantage to doing this is blah.

# 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. [[User:Hsivonen|Hsivonen]] 09:06, 4 August 2008 (UTC)) [[User:aaronlev|aaronlev]] Henri also mentioned that potential legal issues could affect technical issues, but we aren't sure. It would be good if WGBH had some background to help understand this as well while devising a captioning solution.
##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)) [[User:aaronlev|aaronlev]] I'm not sure -- there are some higher level things such as embedding of a musical note graphic to indicate music. I believe that captioning is moving toward expressing more complex background information.
# 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 the solution is compatible with 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.
# Ensure the solition incorporates the expressed needs and preferences of Internet-based media users with sensory disabilities. (( Aaron: what are these? Can we express these up front? WGBH must already know this info, e.g. why would it change based on internet vs. brodcast? ))
# Ensure all solutions, documentation and tests developed are friendly to open source contributors and clean of known IP conflicts
# Participate in the relevant deliberations, meetings, standards development activities and proposed work products of HTML 5 WG.
# 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 a complete set of open-licensed documentation and test cases for developers and content creators. In general, reach out to developers implementing captioning solutions for the web and 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 are well-understood.
# 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.

= 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.

Accessibility/Captioning Work Plan

2008-08-04T09:59:31Z

Aaronlev:

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
# Add points for audio description
# Describe the true complexity of the problem.

= Work plan =

# Determine which captioning format should be supported in Mozilla for the natively-supported Ogg video. This needs to take into account the extremely complex map of video formats and players today. There is both a container and a codec involved for each video format. For a given container, you need to have a defined (and supported by tools and other video players for network effects) mapping for muxing a giving captioning format into the container. So the video codec rules. The container depends on what's conventional for the video codec, and the choice of captioning format depends on what's conventional for the container. In theory, given a muxing rule, you can put any video codec and any captiong format in any container, but in practice, video codec tends to have a conventional native container, so the video codec dictates the container and then different containers have different conventional timed text formats and the timed text formats might not have muxing rules for non-native containers
Example: Ogg and MP4 are containers, whereas Theora and H.264 are codecs.
Gstreamer and QuickTime are both timed media frameworks, which each can play various other container/codec combinations (?). Ogg, Theora and CMML are a natural match. MP4, H.264 and 3GPP TT are a natural match. While technically, you *could* define a way to put 3GPP TT inside Ogg, the disadvantage to doing this is blah.

# 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. [[User:Hsivonen|Hsivonen]] 09:06, 4 August 2008 (UTC)) [[User:aaronlev|aaronlev]] Henri also mentioned that potential legal issues could affect technical issues, but we aren't sure. It would be good if WGBH had some background to help understand this as well while devising a captioning solution.
##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)) [[User:aaronlev|aaronlev]] I'm not sure -- there are some higher level things such as embedding of a musical note graphic to indicate music. I believe that captioning is moving toward expressing more complex background information.
# 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 the solution is compatible with 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.
# Ensure the solition incorporates the expressed needs and preferences of Internet-based media users with sensory disabilities. (( Aaron: what are these? Can we express these up front? WGBH must already know this info, e.g. why would it change based on internet vs. brodcast? ))
# Ensure all solutions, documentation and tests developed are friendly to open source contributors and clean of known IP conflicts
# Participate in the relevant deliberations, meetings, standards development activities and proposed work products of HTML 5 WG.
# 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 a complete set of open-licensed documentation and test cases for developers and content creators. In general, reach out to developers implementing captioning solutions for the web and 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 are well-understood.
# 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.

= 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.

Accessibility/Captioning Work Plan

2008-08-04T09:46:23Z

Aaronlev: /* Work plan */

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
# Is audio description outside the scope? Is the focus captioning only? [[User:Hsivonen|Hsivonen]] 09:10, 4 August 2008 (UTC)

= 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. [[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)) [[User:aaronlev|aaronlev]] I'm not sure -- there are some higher level things such as embedding of a musical note graphic to indicate music. I believe that captioning is moving toward expressing more complex background information.
# 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 the solution is compatible with 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.
# Ensure the solition incorporates the expressed needs and preferences of Internet-based media users with sensory disabilities. (( Aaron: what are these? Can we express these up front? WGBH must already know this info, e.g. why would it change based on internet vs. brodcast? ))
# Ensure all solutions, documentation and tests developed are friendly to open source contributors and clean of known IP conflicts
# Participate in the relevant deliberations, meetings, standards development activities and proposed work products of HTML 5 WG.
# 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 a complete set of open-licensed documentation and test cases for developers and content creators. In general, reach out to developers implementing captioning solutions for the web and 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 are well-understood.
# 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.

= 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.

Accessibility/Captioning Work Plan

2008-08-04T09:42:39Z

Aaronlev:

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
# Is audio description outside the scope? Is the focus captioning only? [[User:Hsivonen|Hsivonen]] 09:10, 4 August 2008 (UTC)

= 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. [[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)) [[User:aaronlev|aaronlev]] I'm not sure -- there are some higher level things such as embedding of a musical note graphic to indicate music. I believe that captioning is moving toward expressing more complex background information.
# 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 the solution is compatible with 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.
# Ensure the solition incorporates the expressed needs and preferences of Internet-based media users with sensory disabilities. (( Aaron: what are these? Can we express these up front? WGBH must already know this info, e.g. why would it change based on internet vs. brodcast? ))
# 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.

= 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.

Accessibility/Captioning Work Plan

2008-08-04T09:40:44Z

Aaronlev: /* Work plan */

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
# Is audio description outside the scope? Is the focus captioning only? [[User:Hsivonen|Hsivonen]] 09:10, 4 August 2008 (UTC)

= 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. [[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)) [[User:aaronlev|aaronlev]] I'm not sure -- there are some higher level things such as embedding of a musical note graphic to indicate music. I believe that captioning is moving toward expressing more complex background information.
# 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.

= 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.

Accessibility/Captioning Work Plan

2008-08-04T09:34:53Z

Aaronlev: /* Previous list that we should merge in */

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
# Is audio description outside the scope? Is the focus captioning only? [[User:Hsivonen|Hsivonen]] 09:10, 4 August 2008 (UTC)

= 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. [[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
# 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.

= 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.

Contributors/Germany Austria Switzerland

2008-08-03T23:08:37Z

Aaronlev:

Here is a list of people in Germany, Austria and Switzerland who work on Mozilla.

This idea was born at the 2008 summit, among the German-speakers there. But, definitely remove yourself from the list if you don't want to be on it.

{| border="1" cellspacing="0" cellpadding="1"
! Name
! IRC
! Email
! City
! Role
! Notes
|-
| Christian Biesinger
| biesi
| cbiesinger__gmail.com
| Zürich
| Core developer
|
|-
| Carsten Book
| tomcat
| tomcat__@mozilla.com
| Pfronten
| QA Engineer
|
|-
| Patrick Brunschwig
|
|
|
| [http://enigmail.mozdev.org/home/index.php Enigmail]
|
|-
| Simon Bünzli
|
|
|
| Front end developer
|
|-
| Karsten Düsterloh
| mnyromyr
| mnyromyr@tprac.de
| Sprockhövel
| Developer: primarily SeaMonkey, Mnenhy, mail/news backend
|
|-
| Bruno Escherl
| aqualon
| aqualon__@aquachan.de
| Erlangen
| SeaMonkey dev (mostly mailnews part)
|
|-
| Dão Gottwald
| dao
| dao__mozilla.com
|
| Front end developer
|
|-
| Axel Hecht
| pike
|
|
|
|
|-
| Romi Harchiyanto
| romi
| romiharchiyanto__gmail.com
| Hamburg
| L10n-id
|
|-
| Alexander Ihrig
|
|
|
| TB L10N
|
|-
| Robert Kaiser
| kairo
|
|
|
|
|-
| Philip Kewisch
| Fallen
|
|
|
|
|-
| Aaron Leventhal
| aaronlev
| aaron__moonset.net
| Esslingen
| A11y developer
| In Germany since April, 2008. [http://accessgarage.wordpress.com/ Blog]
|-
| Wladimir Palant
|
|
|
| Adblock. Ist das nicht genug?
|
|-
| Simon Paquet
|
|
|
|
|
|-
| Martin Schröder
| mschroeder
|
|
|
|
|-
| Henrik Skupin
| whimboo
| mozilla__hskupin.info
| Karlsruhe
| QA, L10n
|
|-
| Markus Stange
| mstange
| mstange__themasta.com
| Mainz
| Mac dev
|
|-
| Abdulkadir Topal
| topal
| o.topal__gmail.com
| Duisburg
| L10n
|
|-
| Frank Wein
| mcsmurf
|
|
|
|
|-
| Frederic Wenzel
| fwenzel
|
|
|
|
|-
| Marco Zehe
| marcoz
| marco.zehe__googlemail.com
| Hamburg
| A11y QA
| [http://marcozehe.de/ blog]
|}

Contributors/Germany Austria Switzerland

2008-08-03T22:51:53Z

Aaronlev:

Here is a list of people in Germany, Austria and Switzerland who work on Mozilla.

This idea was born at the 2008 summit, among the German-speakers there. But, definitely remove yourself from the list if you don't want to be on it.

{| border="1" cellspacing="0" cellpadding="1"
! Name
! IRC
! Email
! City
! Role
! Notes
|-
| Christian Biesinger
| biesi
| cbiesinger__gmail.com
| Zürich
| Core developer
|
|-
| Carsten Book
| tomcat
| tomcat__@mozilla.com
| Pfronten
| QA Engineer
|
|-
| Simon Bünzli
|
|
|
| Front end developer
|
|-
| Karsten Düsterloh
| mnyromyr
|
|
|
|
|-
| Bruno Escherl
| aqualon
| aqualon@aquachan.de
| Erlangen
| SeaMonkey dev (mostly mailnews part)
|
|-
| Dão Gottwald
| dao
| dao__mozilla.com
|
| Front end developer
|
|-
| Axel Hecht
| pike
|
|
|
|
|-
| Romi Harchiyanto
| romi
| romiharchiyanto__gmail.com
| Hamburg
| L10n-id
|
|-
| Alexander Ihrij?
|
|
|
|
|
|-
| Robert Kaiser
| kairo
|
|
|
|
|-
| Philip Kerwisch
|
|
|
|
|
|-
| Aaron Leventhal
| aaronlev
| aaron__moonset.net
| Esslingen
| A11y developer
| In Germany since April, 2008. [http://accessgarage.wordpress.com/ Blog]
|-
| Wladimir Palant
|
|
|
| Adblock. Ist das nicht genug?
|
|-
| Simon Paquet
|
|
|
|
|
|-
| Martin Schröder
| mschroeder
|
|
|
|
|-
| Henrik Skupin
| whimboo
| mozilla__hskupin.info
| Karlsruhe
| QA, L10n
|
|-
| Markus Stange
| mstange
| mstange__themasta.com
| Mainz
| Mac dev
|
|-
| Abdulkadir Topal
| kadir
| o.topal__gmail.com
| Duisburg
| L10n
|
|-
| Frank Wein
| mcsmurf
|
|
|
|
|-
| Frederic Wenzel
| fwenzel
|
|
|
|
|-
| Marco Zehe
| marcoz
| marco.zehe__googlemail.com
| Hamburg
| A11y QA
| [http://marcozehe.de/ blog]
|}

Contributors/Germany Austria Switzerland

2008-08-03T22:39:31Z

Aaronlev:

Here is a list of people in Germany, Austria and Switzerland who work on Mozilla.

This idea was born at the 2008 summit, among the German-speakers there. But, definitely remove yourself from the list if you don't want to be on it.

{| border="1" cellspacing="0" cellpadding="1"
! Name
! IRC
! Email
! City
! Role
! Notes
|-
| Christian Biesinger
| biesi
| cbiesinger__gmail.com
| Zürich
| Core developer
|
|-
| Carsten Book
| tomcat
| tomcat__@mozilla.com
| Pfronten
| QA Engineer
|
|-
| Simon Bünzli
|
|
|
| Front end developer
|
|-
| Karsten Düsterloh
| mnyromyr
|
|
|
|
|-
| Bruno Escherl
| aqualon
| aqualon@aquachan.de
| Erlangen
| SeaMonkey dev (mostly mailnews part)
|
|-
| Dão Gottwald
| dao
| dao__mozilla.com
|
| Front end developer
|
|-
| Axel Hecht
| pike
|
|
|
|
|-
| Romi Harchiyanto
| romi
| romiharchiyanto__gmail.com
| Hamburg
| L10n-id
|
|-
| Alexander Ihrij?
|
|
|
|
|
|-
| Robert Kaiser
| kairo
|
|
|
|
|-
| Philip Kerwisch
|
|
|
|
|
|-
| Aaron Leventhal
| aaronlev
| aaron__moonset.net
| Esslingen
| A11y developer
| In Germany since April, 2008. [http://accessgarage.wordpress.com/ Blog]
|-
| Wladimir Palant
|
|
|
| Adblock. Ist das nicht genug?
|
|-
| Simon Paquet
|
|
|
|
|
|-
| Martin Schröder
| mschroeder
|
|
|
|
|-
| Henrik Skupin
| whimboo
| mozilla__hskupin.info
| Karlsruhe
| QA, L10n
|
|-
| Markus Stange
| mstange
| mstange__themasta.com
| Mainz
| Mac dev
|
|-
| Abdullakadir Topal
| kadir
| o.topal__gmail.com
| Duisburg
| L10n
|
|-
| Frank Wein
| mcsmurf
|
|
|
|
|-
| Frederic Wenzel
| fwenzel
|
|
|
|
|-
| Marco Zehe
| marcoz
| marco.zehe__googlemail.com
| Hamburg
| A11y QA
| [http://marcozehe.de/ blog]
|}