incubator-ooo-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ksch...@apache.org
Subject svn commit: r1206938 [34/35] - in /incubator/ooo/ooo-site/trunk/content/ui/accessibility: ./ apiref/ apiref/com/ apiref/com/sun/ apiref/com/sun/star/ apiref/com/sun/star/accessibility/ apiref/com/sun/star/awt/ apiref/com/sun/star/beans/ apiref/com/sun/...
Date Mon, 28 Nov 2011 00:40:39 GMT
Added: incubator/ooo/ooo-site/trunk/content/ui/accessibility/apiref/index-files/index-8.html
URL: http://svn.apache.org/viewvc/incubator/ooo/ooo-site/trunk/content/ui/accessibility/apiref/index-files/index-8.html?rev=1206938&view=auto
==============================================================================
--- incubator/ooo/ooo-site/trunk/content/ui/accessibility/apiref/index-files/index-8.html (added)
+++ incubator/ooo/ooo-site/trunk/content/ui/accessibility/apiref/index-files/index-8.html Mon Nov 28 00:36:55 2011
@@ -0,0 +1,64 @@
+<html>
+<head>
+<title>Global Index H</title>
+<style>h3 { font-size:13pt; font-weight:bold; margin-top:3pt; margin-bottom:1pt; }
+p, dt, dd, pre  { font-size:11pt; margin-top:3pt; margin-bottom:1pt; }
+table.lightbg { background-color:#eeeeff; }
+table.subtitle { margin-top:6pt; margin-bottom:6pt; }
+td { font-size:11pt; }
+td.title { font-family: Arial; font-size:19pt; font-weight:bold; text-align:center; background-color:#ccccff; line-height:30pt; }
+td.subtitle { font-family: Arial; font-size:13pt; background-color:#ccccff; line-height:20pt; }
+td.imdetail { width:100%; background-color:#eeeeff; }
+a.membertitle { font-size:12pt; font-weight:bold; line-height:18pt; }
+td.imsum_left { width:30%;  }
+td.imsum_right { width:70%;  }
+td.navimain, a.navimain { text-align:center; font-family: Arial; font-size:12pt; font-weight:bold; }
+td.navimainself { text-align:center; font-family: Arial; font-size:12pt; font-weight:bold; color:#ffffff; background-color:#2222ad; }
+td.navimainnone { text-align:center; font-family: Arial; font-size:12pt; }
+td.attrtitle { font-weight:bold; background-color:#eeeeff; }
+td.navisub, a.navisub, td.attrtitle, td.attrvalue { text-align:center; font-family: Arial; font-size:9pt; font-variant:small-caps; }
+td.navimain, td.navisub { padding-left:7pt; padding-right:7pt; }
+p.raise  { font-size:11pt; margin-top:0pt; text-align:right; padding-right:5pt; }
+a.navimain, a.navisub  { color:#000000; }
+.dt     { font-weight:bold; }
+.namechain  { font-size:13pt; font-weight:bold; margin-top:3pt; margin-bottom:6pt; }
+.tpl        { font-size:13pt; margin-top:3pt; margin-bottom:6pt; }
+</style>
+
+<meta HTTP-EQUIV="content-type" CONTENT="text/html; charset=UTF-8">
+</head>
+<body bgcolor="#ffffff">
+<a name="_top_"> </a>
+<table border="0" cellpadding="3" class="lightbg">
+<tr>
+<td class="navimain"><a href="../com/sun/star/module-ix.html" class="navimain">Overview</a></td>
+<td class="navimainnone">Module</td>
+<td class="navimainnone">Use</td>
+<td class="navimainnone">Devguide</td>
+<td class="navimainself">Index</td>
+</tr>
+</table>
+<hr>
+<hr>
+<table border="0" width="100%" cellpadding="5" cellspacing="3" style="margin-bottom:6pt;">
+<tr>
+<td class="title">Global Index H</td>
+</tr>
+<tr>
+<td><p align="center"><a href="index-1.html"><b>A</b></a> <a href="index-2.html"><b>B</b></a> <a href="index-3.html"><b>C</b></a> <a href="index-4.html"><b>D</b></a> <a href="index-5.html"><b>E</b></a> <a href="index-6.html"><b>F</b></a> <a href="index-7.html"><b>G</b></a> <a href="index-8.html"><b>H</b></a> <a href="index-9.html"><b>I</b></a> <a href="index-10.html"><b>J</b></a> <a href="index-11.html"><b>K</b></a> <a href="index-12.html"><b>L</b></a> <a href="index-13.html"><b>M</b></a> <a href="index-14.html"><b>N</b></a> <a href="index-15.html"><b>O</b></a> <a href="index-16.html"><b>P</b></a> <a href="index-17.html"><b>Q</b></a> <a href="index-18.html"><b>R</b></a> <a href="index-19.html"><b>S</b></a> <a href="index-20.html"><b>T</b></a> <a href="index-21.html"><b>U</b></a> <a href="index-22.html"><b>V</b></a> <a href="index-23.html"><b>W</b></a> <a href="index-24.html"><b>X</b></a> <a href="index-25.html"><b>Y</b></a> <a href="index-26.html"><b>Z</b></a> <a href="index
 -27.html"><b>_</b></a></p></td>
+</tr>
+</table>
+<dl>
+<dt><a href="../drafts/com/sun/star/accessibility/AccessibleRole.html#HEADER"><b>HEADER</b></a> - constant in constants group ::drafts::com::sun::star::accessibility:: .<a href="../drafts/com/sun/star/accessibility/AccessibleRole.html">AccessibleRole</a></dt>
+<dd/><dt><a href="../drafts/com/sun/star/accessibility/AccessibleRole.html#HEADING"><b>HEADING</b></a> - constant in constants group ::drafts::com::sun::star::accessibility:: .<a href="../drafts/com/sun/star/accessibility/AccessibleRole.html">AccessibleRole</a></dt>
+<dd/><dt><a href="../drafts/com/sun/star/frame/DispatchInformation.html#HelpText"><b>HelpText</b></a> - field in struct ::drafts::com::sun::star::frame:: .<a href="../drafts/com/sun/star/frame/DispatchInformation.html">DispatchInformation</a></dt>
+<dd/><dt><a href="../drafts/com/sun/star/ui/ActionTrigger.html#HelpURL"><b>HelpURL</b></a> - property in service ::drafts::com::sun::star::ui:: .<a href="../drafts/com/sun/star/ui/ActionTrigger.html">ActionTrigger</a></dt>
+<dd/><dt><a href="../drafts/com/sun/star/accessibility/AccessibleStateType.html#HORIZONTAL"><b>HORIZONTAL</b></a> - constant in constants group ::drafts::com::sun::star::accessibility:: .<a href="../drafts/com/sun/star/accessibility/AccessibleStateType.html">AccessibleStateType</a></dt>
+<dd/><dt><a href="../drafts/com/sun/star/accessibility/AccessibleRole.html#HYPERLINK"><b>HYPERLINK</b></a> - constant in constants group ::drafts::com::sun::star::accessibility:: .<a href="../drafts/com/sun/star/accessibility/AccessibleRole.html">AccessibleRole</a></dt>
+<dd/><dt><a href="../drafts/com/sun/star/accessibility/AccessibleRole.html#HYPER_LINK"><b>HYPER_LINK</b></a> - constant in constants group ::drafts::com::sun::star::accessibility:: .<a href="../drafts/com/sun/star/accessibility/AccessibleRole.html">AccessibleRole</a></dt>
+<dd/></dl>
+<hr>
+<a href="#_top_">Top of Page</a><hr size="3"><p class="copyright" align="center">Copyright &copy; 2003 Sun Microsystems, Inc.</p>
+</body>
+
+</html>

Propchange: incubator/ooo/ooo-site/trunk/content/ui/accessibility/apiref/index-files/index-8.html
------------------------------------------------------------------------------
    svn:eol-style = native

Added: incubator/ooo/ooo-site/trunk/content/ui/accessibility/apiref/index-files/index-9.html
URL: http://svn.apache.org/viewvc/incubator/ooo/ooo-site/trunk/content/ui/accessibility/apiref/index-files/index-9.html?rev=1206938&view=auto
==============================================================================
--- incubator/ooo/ooo-site/trunk/content/ui/accessibility/apiref/index-files/index-9.html (added)
+++ incubator/ooo/ooo-site/trunk/content/ui/accessibility/apiref/index-files/index-9.html Mon Nov 28 00:36:55 2011
@@ -0,0 +1,91 @@
+<html>
+<head>
+<title>Global Index I</title>
+<style>h3 { font-size:13pt; font-weight:bold; margin-top:3pt; margin-bottom:1pt; }
+p, dt, dd, pre  { font-size:11pt; margin-top:3pt; margin-bottom:1pt; }
+table.lightbg { background-color:#eeeeff; }
+table.subtitle { margin-top:6pt; margin-bottom:6pt; }
+td { font-size:11pt; }
+td.title { font-family: Arial; font-size:19pt; font-weight:bold; text-align:center; background-color:#ccccff; line-height:30pt; }
+td.subtitle { font-family: Arial; font-size:13pt; background-color:#ccccff; line-height:20pt; }
+td.imdetail { width:100%; background-color:#eeeeff; }
+a.membertitle { font-size:12pt; font-weight:bold; line-height:18pt; }
+td.imsum_left { width:30%;  }
+td.imsum_right { width:70%;  }
+td.navimain, a.navimain { text-align:center; font-family: Arial; font-size:12pt; font-weight:bold; }
+td.navimainself { text-align:center; font-family: Arial; font-size:12pt; font-weight:bold; color:#ffffff; background-color:#2222ad; }
+td.navimainnone { text-align:center; font-family: Arial; font-size:12pt; }
+td.attrtitle { font-weight:bold; background-color:#eeeeff; }
+td.navisub, a.navisub, td.attrtitle, td.attrvalue { text-align:center; font-family: Arial; font-size:9pt; font-variant:small-caps; }
+td.navimain, td.navisub { padding-left:7pt; padding-right:7pt; }
+p.raise  { font-size:11pt; margin-top:0pt; text-align:right; padding-right:5pt; }
+a.navimain, a.navisub  { color:#000000; }
+.dt     { font-weight:bold; }
+.namechain  { font-size:13pt; font-weight:bold; margin-top:3pt; margin-bottom:6pt; }
+.tpl        { font-size:13pt; margin-top:3pt; margin-bottom:6pt; }
+</style>
+
+<meta HTTP-EQUIV="content-type" CONTENT="text/html; charset=UTF-8">
+</head>
+<body bgcolor="#ffffff">
+<a name="_top_"> </a>
+<table border="0" cellpadding="3" class="lightbg">
+<tr>
+<td class="navimain"><a href="../com/sun/star/module-ix.html" class="navimain">Overview</a></td>
+<td class="navimainnone">Module</td>
+<td class="navimainnone">Use</td>
+<td class="navimainnone">Devguide</td>
+<td class="navimainself">Index</td>
+</tr>
+</table>
+<hr>
+<hr>
+<table border="0" width="100%" cellpadding="5" cellspacing="3" style="margin-bottom:6pt;">
+<tr>
+<td class="title">Global Index I</td>
+</tr>
+<tr>
+<td><p align="center"><a href="index-1.html"><b>A</b></a> <a href="index-2.html"><b>B</b></a> <a href="index-3.html"><b>C</b></a> <a href="index-4.html"><b>D</b></a> <a href="index-5.html"><b>E</b></a> <a href="index-6.html"><b>F</b></a> <a href="index-7.html"><b>G</b></a> <a href="index-8.html"><b>H</b></a> <a href="index-9.html"><b>I</b></a> <a href="index-10.html"><b>J</b></a> <a href="index-11.html"><b>K</b></a> <a href="index-12.html"><b>L</b></a> <a href="index-13.html"><b>M</b></a> <a href="index-14.html"><b>N</b></a> <a href="index-15.html"><b>O</b></a> <a href="index-16.html"><b>P</b></a> <a href="index-17.html"><b>Q</b></a> <a href="index-18.html"><b>R</b></a> <a href="index-19.html"><b>S</b></a> <a href="index-20.html"><b>T</b></a> <a href="index-21.html"><b>U</b></a> <a href="index-22.html"><b>V</b></a> <a href="index-23.html"><b>W</b></a> <a href="index-24.html"><b>X</b></a> <a href="index-25.html"><b>Y</b></a> <a href="index-26.html"><b>Z</b></a> <a href="index
 -27.html"><b>_</b></a></p></td>
+</tr>
+</table>
+<dl>
+<dt><a href="../drafts/com/sun/star/accessibility/AccessibleRole.html#ICON"><b>ICON</b></a> - constant in constants group ::drafts::com::sun::star::accessibility:: .<a href="../drafts/com/sun/star/accessibility/AccessibleRole.html">AccessibleRole</a></dt>
+<dd/><dt><a href="../drafts/com/sun/star/accessibility/AccessibleStateType.html#ICONIFIED"><b>ICONIFIED</b></a> - constant in constants group ::drafts::com::sun::star::accessibility:: .<a href="../drafts/com/sun/star/accessibility/AccessibleStateType.html">AccessibleStateType</a></dt>
+<dd/><dt><a href="../drafts/com/sun/star/ui/ContextMenuInterceptorAction.html#IGNORED"><b>IGNORED</b></a> - value in enum ::drafts::com::sun::star::ui:: .<a href="../drafts/com/sun/star/ui/ContextMenuInterceptorAction.html">ContextMenuInterceptorAction</a></dt>
+<dd/><dt><a href="../drafts/com/sun/star/accessibility/IllegalAccessibleComponentStateException.html"><b>IllegalAccessibleComponentStateException</b></a> - exception in module ::drafts::com::sun::star:: .<a href="../drafts/com/sun/star/accessibility/module-ix.html"><b>accessibility</b></a></dt>
+<dd/><dt><a href="../drafts/com/sun/star/accessibility/IllegalComponentStateException.html"><b>IllegalComponentStateException</b></a> - exception in module ::drafts::com::sun::star:: .<a href="../drafts/com/sun/star/accessibility/module-ix.html"><b>accessibility</b></a></dt>
+<dd/><dt><a href="../drafts/com/sun/star/ui/ActionTrigger.html#Image"><b>Image</b></a> - property in service ::drafts::com::sun::star::ui:: .<a href="../drafts/com/sun/star/ui/ActionTrigger.html">ActionTrigger</a></dt>
+<dd/><dt><a href="../drafts/com/sun/star/configuration/backend/XSchemaHandler.html#importComponent"><b>importComponent()</b></a> - function in interface ::drafts::com::sun::star::configuration::backend:: .<a href="../drafts/com/sun/star/configuration/backend/XSchemaHandler.html">XSchemaHandler</a></dt>
+<dd/><dt><a href="../drafts/com/sun/star/configuration/backend/XImportLayer.html#importLayer"><b>importLayer()</b></a> - function in interface ::drafts::com::sun::star::configuration::backend:: .<a href="../drafts/com/sun/star/configuration/backend/XImportLayer.html">XImportLayer</a></dt>
+<dd/><dt><a href="../drafts/com/sun/star/configuration/backend/XImportLayer.html#importLayerForEntity"><b>importLayerForEntity()</b></a> - function in interface ::drafts::com::sun::star::configuration::backend:: .<a href="../drafts/com/sun/star/configuration/backend/XImportLayer.html">XImportLayer</a></dt>
+<dd/><dt><a href="../drafts/com/sun/star/auth/XSSOInitiatorContext.html#init"><b>init()</b></a> - function in interface ::drafts::com::sun::star::auth:: .<a href="../drafts/com/sun/star/auth/XSSOInitiatorContext.html">XSSOInitiatorContext</a></dt>
+<dd/><dt><a href="../drafts/com/sun/star/i18n/InputSequenceCheckMode.html"><b>InputSequenceCheckMode</b></a> - constants group in module ::drafts::com::sun::star:: .<a href="../drafts/com/sun/star/i18n/module-ix.html"><b>i18n</b></a></dt>
+<dd/><dt><a href="../drafts/com/sun/star/accessibility/AccessibleTableModelChangeType.html#INSERT"><b>INSERT</b></a> - constant in constants group ::drafts::com::sun::star::accessibility:: .<a href="../drafts/com/sun/star/accessibility/AccessibleTableModelChangeType.html">AccessibleTableModelChangeType</a></dt>
+<dd/><dt><a href="../drafts/com/sun/star/accessibility/XAccessibleEditableText.html#insertText"><b>insertText()</b></a> - function in interface ::drafts::com::sun::star::accessibility:: .<a href="../drafts/com/sun/star/accessibility/XAccessibleEditableText.html">XAccessibleEditableText</a></dt>
+<dd/><dt><a href="../drafts/com/sun/star/configuration/backend/InsufficientAccessRightsException.html"><b>InsufficientAccessRightsException</b></a> - exception in module ::drafts::com::sun::star::configuration:: .<a href="../drafts/com/sun/star/configuration/backend/module-ix.html"><b>backend</b></a></dt>
+<dd/><dt><a href="../drafts/com/sun/star/accessibility/AccessibleRole.html#INTERNALFRAME"><b>INTERNALFRAME</b></a> - constant in constants group ::drafts::com::sun::star::accessibility:: .<a href="../drafts/com/sun/star/accessibility/AccessibleRole.html">AccessibleRole</a></dt>
+<dd/><dt><a href="../drafts/com/sun/star/accessibility/AccessibleRole.html#INTERNAL_FRAME"><b>INTERNAL_FRAME</b></a> - constant in constants group ::drafts::com::sun::star::accessibility:: .<a href="../drafts/com/sun/star/accessibility/AccessibleRole.html">AccessibleRole</a></dt>
+<dd/><dt><a href="../drafts/com/sun/star/accessibility/AccessibleStateType.html#INVALID"><b>INVALID</b></a> - constant in constants group ::drafts::com::sun::star::accessibility:: .<a href="../drafts/com/sun/star/accessibility/AccessibleStateType.html">AccessibleStateType</a></dt>
+<dd/><dt><a href="../drafts/com/sun/star/accessibility/AccessibleRelationType.html#INVALID"><b>INVALID</b></a> - constant in constants group ::drafts::com::sun::star::accessibility:: .<a href="../drafts/com/sun/star/accessibility/AccessibleRelationType.html">AccessibleRelationType</a></dt>
+<dd/><dt><a href="../drafts/com/sun/star/auth/InvalidArgumentException.html"><b>InvalidArgumentException</b></a> - exception in module ::drafts::com::sun::star:: .<a href="../drafts/com/sun/star/auth/module-ix.html"><b>auth</b></a></dt>
+<dd/><dt><a href="../drafts/com/sun/star/configuration/backend/InvalidAuthenticationMechanismException.html"><b>InvalidAuthenticationMechanismException</b></a> - exception in module ::drafts::com::sun::star::configuration:: .<a href="../drafts/com/sun/star/configuration/backend/module-ix.html"><b>backend</b></a></dt>
+<dd/><dt><a href="../drafts/com/sun/star/auth/InvalidContextException.html"><b>InvalidContextException</b></a> - exception in module ::drafts::com::sun::star:: .<a href="../drafts/com/sun/star/auth/module-ix.html"><b>auth</b></a></dt>
+<dd/><dt><a href="../drafts/com/sun/star/auth/InvalidCredentialException.html"><b>InvalidCredentialException</b></a> - exception in module ::drafts::com::sun::star:: .<a href="../drafts/com/sun/star/auth/module-ix.html"><b>auth</b></a></dt>
+<dd/><dt><a href="../drafts/com/sun/star/auth/InvalidPrincipalException.html"><b>InvalidPrincipalException</b></a> - exception in module ::drafts::com::sun::star:: .<a href="../drafts/com/sun/star/auth/module-ix.html"><b>auth</b></a></dt>
+<dd/><dt><a href="../drafts/com/sun/star/accessibility/XAccessibleSelection.html#isAccessibleChildSelected"><b>isAccessibleChildSelected()</b></a> - function in interface ::drafts::com::sun::star::accessibility:: .<a href="../drafts/com/sun/star/accessibility/XAccessibleSelection.html">XAccessibleSelection</a></dt>
+<dd/><dt><a href="../drafts/com/sun/star/accessibility/XAccessibleTable.html#isAccessibleColumnSelected"><b>isAccessibleColumnSelected()</b></a> - function in interface ::drafts::com::sun::star::accessibility:: .<a href="../drafts/com/sun/star/accessibility/XAccessibleTable.html">XAccessibleTable</a></dt>
+<dd/><dt><a href="../drafts/com/sun/star/accessibility/XAccessibleTable.html#isAccessibleRowSelected"><b>isAccessibleRowSelected()</b></a> - function in interface ::drafts::com::sun::star::accessibility:: .<a href="../drafts/com/sun/star/accessibility/XAccessibleTable.html">XAccessibleTable</a></dt>
+<dd/><dt><a href="../drafts/com/sun/star/accessibility/XAccessibleTable.html#isAccessibleSelected"><b>isAccessibleSelected()</b></a> - function in interface ::drafts::com::sun::star::accessibility:: .<a href="../drafts/com/sun/star/accessibility/XAccessibleTable.html">XAccessibleTable</a></dt>
+<dd/><dt><a href="../drafts/com/sun/star/ui/ActionTrigger.html#IsCheckable"><b>IsCheckable</b></a> - property in service ::drafts::com::sun::star::ui:: .<a href="../drafts/com/sun/star/ui/ActionTrigger.html">ActionTrigger</a></dt>
+<dd/><dt><a href="../drafts/com/sun/star/accessibility/XAccessibleStateSet.html#isEmpty"><b>isEmpty()</b></a> - function in interface ::drafts::com::sun::star::accessibility:: .<a href="../drafts/com/sun/star/accessibility/XAccessibleStateSet.html">XAccessibleStateSet</a></dt>
+<dd/><dt><a href="../drafts/com/sun/star/ui/ActionTrigger.html#IsEnabled"><b>IsEnabled</b></a> - property in service ::drafts::com::sun::star::ui:: .<a href="../drafts/com/sun/star/ui/ActionTrigger.html">ActionTrigger</a></dt>
+<dd/><dt><a href="../drafts/com/sun/star/ui/ActionTrigger.html#IsRadioCheck"><b>IsRadioCheck</b></a> - property in service ::drafts::com::sun::star::ui:: .<a href="../drafts/com/sun/star/ui/ActionTrigger.html">ActionTrigger</a></dt>
+<dd/><dt><a href="../drafts/com/sun/star/accessibility/XAccessibleHyperlink.html#isValid"><b>isValid()</b></a> - function in interface ::drafts::com::sun::star::accessibility:: .<a href="../drafts/com/sun/star/accessibility/XAccessibleHyperlink.html">XAccessibleHyperlink</a></dt>
+<dd/><dt><a href="../drafts/com/sun/star/i18n/XNativeNumberSupplier.html#isValidNatNum"><b>isValidNatNum()</b></a> - function in interface ::drafts::com::sun::star::i18n:: .<a href="../drafts/com/sun/star/i18n/XNativeNumberSupplier.html">XNativeNumberSupplier</a></dt>
+<dd/><dt><a href="../drafts/com/sun/star/i18n/module-ix.html"><b>i18n</b></a> - module in module ::drafts::com::sun:: .<a href="../drafts/com/sun/star/module-ix.html"><b>star</b></a></dt>
+<dd/></dl>
+<hr>
+<a href="#_top_">Top of Page</a><hr size="3"><p class="copyright" align="center">Copyright &copy; 2003 Sun Microsystems, Inc.</p>
+</body>
+
+</html>

Propchange: incubator/ooo/ooo-site/trunk/content/ui/accessibility/apiref/index-files/index-9.html
------------------------------------------------------------------------------
    svn:eol-style = native

Added: incubator/ooo/ooo-site/trunk/content/ui/accessibility/apiref/module-ix.html
URL: http://svn.apache.org/viewvc/incubator/ooo/ooo-site/trunk/content/ui/accessibility/apiref/module-ix.html?rev=1206938&view=auto
==============================================================================
--- incubator/ooo/ooo-site/trunk/content/ui/accessibility/apiref/module-ix.html (added)
+++ incubator/ooo/ooo-site/trunk/content/ui/accessibility/apiref/module-ix.html Mon Nov 28 00:36:55 2011
@@ -0,0 +1,80 @@
+<html>
+<head>
+<title>Module </title>
+<style>h3 { font-size:13pt; font-weight:bold; margin-top:3pt; margin-bottom:1pt; }
+p, dt, dd, pre  { font-size:11pt; margin-top:3pt; margin-bottom:1pt; }
+table.lightbg { background-color:#eeeeff; }
+table.subtitle { margin-top:6pt; margin-bottom:6pt; }
+td { font-size:11pt; }
+td.title { font-family: Arial; font-size:19pt; font-weight:bold; text-align:center; background-color:#ccccff; line-height:30pt; }
+td.subtitle { font-family: Arial; font-size:13pt; background-color:#ccccff; line-height:20pt; }
+td.imdetail { width:100%; background-color:#eeeeff; }
+a.membertitle { font-size:12pt; font-weight:bold; line-height:18pt; }
+td.imsum_left { width:30%;  }
+td.imsum_right { width:70%;  }
+td.navimain, a.navimain { text-align:center; font-family: Arial; font-size:12pt; font-weight:bold; }
+td.navimainself { text-align:center; font-family: Arial; font-size:12pt; font-weight:bold; color:#ffffff; background-color:#2222ad; }
+td.navimainnone { text-align:center; font-family: Arial; font-size:12pt; }
+td.attrtitle { font-weight:bold; background-color:#eeeeff; }
+td.navisub, a.navisub, td.attrtitle, td.attrvalue { text-align:center; font-family: Arial; font-size:9pt; font-variant:small-caps; }
+td.navimain, td.navisub { padding-left:7pt; padding-right:7pt; }
+p.raise  { font-size:11pt; margin-top:0pt; text-align:right; padding-right:5pt; }
+a.navimain, a.navisub  { color:#000000; }
+.dt     { font-weight:bold; }
+.namechain  { font-size:13pt; font-weight:bold; margin-top:3pt; margin-bottom:6pt; }
+.tpl        { font-size:13pt; margin-top:3pt; margin-bottom:6pt; }
+</style>
+
+<meta HTTP-EQUIV="content-type" CONTENT="text/html; charset=UTF-8">
+</head>
+<body bgcolor="#ffffff">
+<a name="_top_"> </a>
+<table border="0" cellpadding="3" class="lightbg">
+<tr>
+<td class="navimain"><a href="com/sun/star/module-ix.html" class="navimain">Overview</a></td>
+<td class="navimainself">Module</td>
+<td class="navimainnone">Use</td>
+<td class="navimainnone">Devguide</td>
+<td class="navimain"><a href="index-files/index-1.html" class="navimain">Index</a></td>
+</tr>
+</table>
+<table border="0" cellpadding="0">
+<tr>
+<td class="navisub"><a href="#NestedModules" class="navisub">Nested Modules</a></td>
+<td class="navisub">Services</td>
+<td class="navisub">Singletons</td>
+<td class="navisub">Interfaces</td>
+<td class="navisub">Structs</td>
+<td class="navisub">Exceptions</td>
+<td class="navisub">Enums</td>
+<td class="navisub">Typedefs</td>
+<td class="navisub">Constant Groups</td>
+</tr>
+</table>
+<hr>
+<table border="0" width="100%" cellpadding="5" cellspacing="3" style="margin-bottom:6pt;">
+<tr>
+<td><p class="namechain"/></td>
+</tr>
+<tr>
+<td class="title">Global Module</td>
+</tr>
+<tr>
+<td/></tr>
+</table>
+<hr>
+<a name="NestedModules"/><table border="1" width="100%" cellpadding="5" cellspacing="0" class="subtitle">
+<tr>
+<td class="subtitle" colspan="2">Nested Modules</td>
+</tr>
+<tr>
+<td class="imsum_left"><a href="com/module-ix.html">com</a></td>
+<td class="imsum_right"/></tr>
+<tr>
+<td class="imsum_left"><a href="drafts/module-ix.html">drafts</a></td>
+<td class="imsum_right"/></tr>
+</table>
+<a href="#_top_">Top of Page</a><hr size="3"><p class="copyright" align="center">Copyright &copy; 2003 Sun Microsystems, Inc.</p>
+</body>
+
+</html>

Propchange: incubator/ooo/ooo-site/trunk/content/ui/accessibility/apiref/module-ix.html
------------------------------------------------------------------------------
    svn:eol-style = native

Added: incubator/ooo/ooo-site/trunk/content/ui/accessibility/apiref/package-list
URL: http://svn.apache.org/viewvc/incubator/ooo/ooo-site/trunk/content/ui/accessibility/apiref/package-list?rev=1206938&view=auto
==============================================================================
--- incubator/ooo/ooo-site/trunk/content/ui/accessibility/apiref/package-list (added)
+++ incubator/ooo/ooo-site/trunk/content/ui/accessibility/apiref/package-list Mon Nov 28 00:36:55 2011
@@ -0,0 +1,15 @@
+drafts
+drafts.com
+drafts.com.sun
+drafts.com.sun.star
+drafts.com.sun.star.drawing
+drafts.com.sun.star.accessibility
+drafts.com.sun.star.accessibility.bridge
+com
+com.sun
+com.sun.star
+com.sun.star.util
+com.sun.star.uno
+com.sun.star.lang
+com.sun.star.beans
+com.sun.star.awt

Propchange: incubator/ooo/ooo-site/trunk/content/ui/accessibility/apiref/package-list
------------------------------------------------------------------------------
    svn:executable = *

Added: incubator/ooo/ooo-site/trunk/content/ui/accessibility/apiref/update.pl
URL: http://svn.apache.org/viewvc/incubator/ooo/ooo-site/trunk/content/ui/accessibility/apiref/update.pl?rev=1206938&view=auto
==============================================================================
--- incubator/ooo/ooo-site/trunk/content/ui/accessibility/apiref/update.pl (added)
+++ incubator/ooo/ooo-site/trunk/content/ui/accessibility/apiref/update.pl Mon Nov 28 00:36:55 2011
@@ -0,0 +1,73 @@
+#! /usr/bin/perl -w
+
+use strict;
+
+# Update the autodoc documentation of the accessibility API.
+
+my @LocallyModified = ();
+my @UnknownFiles = ();
+
+my $CvsCommitPrefix = "cvs commit -m \"updating accessibility documentation\"";
+
+sub get_file_list ()
+{
+    my ($filename, $status, $revision, $fullname);
+
+    open CMD, "cvs status 2>1 |";
+    while (<CMD>)
+    {
+        if (/^\?(.*)/)
+        {
+            if ($1 ne "update.pl")
+            {
+                push @UnknownFiles, $1;
+            }
+        }
+        elsif (/File: (.+?)\s+Status: (.+)/)
+        {
+            $filename = $1;
+            $status = $2;
+        }
+        elsif (/Repository revision:\s+(.+?)\s+\/cvs\/ui\/www\/accessibility\/apiref\/(.+?),v/)
+        {
+            $revision = $1;
+            $fullname = $2;
+            push @LocallyModified, [$fullname, $revision];
+        }
+    }
+    close CMD;
+
+    print "\n";
+    print "there are " . ($#UnknownFiles < 0 ? "no" : $#UnknownFiles) . " unknown files\n";
+    print "there are " . $#LocallyModified . " locally modified files\n";
+}
+
+
+
+
+sub add_unknown_files ()
+{
+    foreach my $fullname (@UnknownFiles)
+    {
+        print "adding " . $fullname . "\n";
+        system ("cvs add " . $fullname);
+        system ($CvsCommitPrefix . " " . $fullname);
+    }
+}
+
+
+sub commit_modified_files ()
+{
+    print "commiting modified files";
+    my $command = $CvsCommitPrefix;
+    foreach my $filedescriptor (@LocallyModified)
+    {
+        my $fullname = $filedescriptor->[0];
+        print "--> $fullname\n";
+#        system ($command . " " . $filedescriptor->[0]);
+    }
+}
+
+get_file_list ();
+#add_unknown_files ();
+#commit_modified_files ();

Propchange: incubator/ooo/ooo-site/trunk/content/ui/accessibility/apiref/update.pl
------------------------------------------------------------------------------
    svn:eol-style = native

Propchange: incubator/ooo/ooo-site/trunk/content/ui/accessibility/apiref/update.pl
------------------------------------------------------------------------------
    svn:executable = *

Added: incubator/ooo/ooo-site/trunk/content/ui/accessibility/at-support.html
URL: http://svn.apache.org/viewvc/incubator/ooo/ooo-site/trunk/content/ui/accessibility/at-support.html?rev=1206938&view=auto
==============================================================================
--- incubator/ooo/ooo-site/trunk/content/ui/accessibility/at-support.html (added)
+++ incubator/ooo/ooo-site/trunk/content/ui/accessibility/at-support.html Mon Nov 28 00:36:55 2011
@@ -0,0 +1,153 @@
+<html><head>
+<meta HTTP-EQUIV="content-type" CONTENT="text/html; charset=UTF-8">
+</head>
+<body>
+<h2>Support of Assistive Technology</h2>
+
+<p>OpenOffice.org lets users create, modify, view, and print documents
+easily and intuitively by providing a graphical user interface (GUI).
+Accessibility is about enabling users who can not use such a graphical user
+interface do the same things.  This is done by using Assistive Technology to
+provide alternative user interfaces (UIs) that are suitable to such
+users.</p>
+
+<p>We could of course change the whole UI and replace it with an
+  altogether different one.  But that has two major drawbacks:
+<ul>
+<li>Two people with different abilities could not help each other
+  because their user interfaces had nothing or very little in
+  common.</li>
+<li>We would have to provide a special UI for every AT device.  The
+  vendor of such a device knows much better than we do, how the UI for
+  their device should look or sound like.</li>
+</ul>
+</p>
+
+<p>A much better solution is to use a generic representation of both
+document and existing GUI that grants AT devices full access to them.  The
+AT device vendors can then use this abstraction to provide an
+<em>additional</em> user interface.  This way both the graphical and the
+alternative user interface are available at the same time and thus people
+that use them can work together on the same document.</p>
+
+<p>For this generic representation we will support both the Java
+Accessibility API (JAA) as well as the Gnome Accessibility API with a
+two-layer architecture: The OpenOffice.org applications themselves implement
+our own UNO Accessibility API (UAA).  The UAA is independent from but
+influenced by the Accessibility APIs of Java and Gnome.  In the second layer
+the UNO Accessibility API is then bridged to the Java and Gnome
+Accessibility APIs.</p>
+
+
+
+<h3>UNO Accessibility API</h3> 
+<p>The UNO Accessibility API (UAA) is described in more detail 
+<a
+href="unoapi.html" 
+title="Description of the UNO Accessibility API">here</a>.  
+It defines a set of interfaces and services that are implemented by all UNO
+objects that belong to the GUI.  Corresponding to the tree hierarchy of
+graphical user interfaces the UAA represents the GUI as a tree of accessible
+objects which can be queried by AT about properties like names, roles,
+geometry, and color.</p>
+
+
+
+<h3>Bridging the UNO Accessibility API to Java and Gnome</h3>
+<p>Bridging the UNO Accessibility API to the Java Accessibility API (JAA) on
+Windows allows OpenOffice.org to utilize the work that Assistive Technology
+(AT) Tool vendors have already done to make Java applications accessible on
+that platform. While the Microsoft Accessibility API only covers a small
+subset of user interface objects like menus and such, the JAA of JDK 1.4
+features additional interface to describe also documents sufficiently.</p>
+
+<p>A similar bridge to the Gnome Accessibility API takes advantage of
+  already existing AT tools that use that API and that run under Solaris and Linux.</p>
+
+
+<h3>Document representation</h3>
+<p>All elements of an OpenOffice.org application that are visible on the
+  screen have to be represented by to UAA to be made accessible to the AT
+  and thus to the user.  For Java GUIs like menus,
+  buttons, and text fields accessibility implementations already exist.  The
+  OpenOffice.org widgets try to be consistent in their accessibility
+  behavior with their Java counterparts.</p>
+
+<p>For the central part of every application window, the document window in
+  which a document is visualized, a corresponding Java implementation does not
+  exist.  We thus had to define our own guidelines how to make document views
+  accessible.</p>
+
+<p>The <a href="docrep-guidelines.html" 
+title="Guidelines for document representation">guidelines of document
+representation</a> describe the general design principles of how to make
+  document views accessible and are independent from the application with
+  which the document is edited.</p>
+
+<p>However, the document representation differs for the different
+  OpenOffice.org applications.  You can find links to the descriptions of
+  the document representation for the individual applications below: <ul>
+  <li><b>Writer</b><br>
+	<a href="proposal-writer.html"
+	title="Proposal of the representation of writer documents">Proposal</a> of 
+	how to make Writer and Writer/Web accessible.</li>
+<li><b>Calc</b><br>
+	<a href="proposal-calc.html"
+	title="Proposal of the representation of calc documents">Proposal</a> of
+    how to make Calc accessible.</li>
+<li><b>Draw/Impress</b><br>
+	<a href="proposal-impress.html" 
+       title="Proposal of Draw/Impress Accessibility Design">Proposal</a> of
+    how to make Draw and Impress accessible.</li>
+<li><b>Chart</b><br>
+	<a href="proposal-chart.html" 
+       title="Proposal of Chart Accessibility Design">Proposal</a> of how to
+    make Chart accessible.</li>
+</ul>
+</p>
+
+<p>More concrete documentation can be found in the services of <a
+href="http://api.openoffice.org/docs/common/ref/com/sun/star/text/module-ix.html" 
+title="Services of theUAA implementation used by the Writer">Writer</a>, 
+<a href="http://api.openoffice.org/docs/common/ref/com/sun/star/sheet/module-ix.html" 
+title="Services of the UAA implementation used by the Calc">Calc</a>, 
+<a href="http://api.openoffice.org/docs/common/ref/com/sun/star/drawing/module-ix.html" 
+title="Services of the UAA implementation used by Draw/Impress">Draw/Impress</a>,
+and <a href="http://api.openoffice.org/docs/common/ref/com/sun/star/chart/module-ix.html" 
+title="Services of the UAA implementation used by Chart">Chart</a>.</p>
+
+<h3>Testing and Debugging</h3>
+<p>There is a graphical test tool, the <a href="AWB.html" 
+title="Description of the AWB test tool">Accessibility Work Bench</a>, that
+  uses the UNO Accessibility API to retrieve the accessibility tree from
+  running OpenOffice.org applications.  It allows developers of the UAA to
+  see what information is available from the outside.</p>
+
+
+<h3>Details of API support</h3>
+<p>This sections describes the more technical details of supporting the
+accessibility APIs.</p>
+
+<p>The general strategy will be to extend the OpenOffice.org API by an
+accessibility section.  This accessibility API, which will be closely
+modeled after the Java and Gnome Accessibility API, can then be mapped
+easily on either of that two.</p>
+
+<p>Using our own OpenOffice.org Accessibility API as an intermediate layer
+  between the office and the accessibility APIs used by AT
+  devices has the advantage that we can easily support more then one
+  API and can react flexible to future changes in those APIs.</p>
+
+<p>We will exploit the fact that we already have an API, that gives
+access to all the details of OpenOffice.org documents.  This allows us to
+gather all code, that implements the OpenOffice.org Accessibility API, in
+one place, rather than to insert it at a very many places into
+existing source.
+</p>
+
+<p>Details about the UAA and its implementation can be found <a
+href="unoapi.html" 
+title="Description of the UNO Accessibility API">here</a>.</p>
+</body>
+</html>
+

Propchange: incubator/ooo/ooo-site/trunk/content/ui/accessibility/at-support.html
------------------------------------------------------------------------------
    svn:eol-style = native

Added: incubator/ooo/ooo-site/trunk/content/ui/accessibility/awb.png
URL: http://svn.apache.org/viewvc/incubator/ooo/ooo-site/trunk/content/ui/accessibility/awb.png?rev=1206938&view=auto
==============================================================================
Binary file - no diff available.

Propchange: incubator/ooo/ooo-site/trunk/content/ui/accessibility/awb.png
------------------------------------------------------------------------------
    svn:mime-type = image/png

Added: incubator/ooo/ooo-site/trunk/content/ui/accessibility/disabilities.html
URL: http://svn.apache.org/viewvc/incubator/ooo/ooo-site/trunk/content/ui/accessibility/disabilities.html?rev=1206938&view=auto
==============================================================================
--- incubator/ooo/ooo-site/trunk/content/ui/accessibility/disabilities.html (added)
+++ incubator/ooo/ooo-site/trunk/content/ui/accessibility/disabilities.html Mon Nov 28 00:36:55 2011
@@ -0,0 +1,76 @@
+<html><head>
+<meta HTTP-EQUIV="content-type" CONTENT="text/html; charset=UTF-8">
+</head>
+<body>
+<h2><a name="disabilities">Disabilities and Assistive Technology</a></h2>
+
+<p>Here is a list of the different kinds of disabilities and what we can
+do to assist people that have such disabilities:
+
+<ul> <li><b>Low Vision</b><br>
+	<ul>
+	<li>Support larger fonts and graphics (icons) or a
+	  screen magnifier.</li>
+	<li>Use clearer fonts, i.e. provide the ability to replace for instance
+      a handwriting font by Helvetica.</li>
+	<li>Enlarge contrast between foreground and background.</li>
+	<li>Remove or avoid distracting background patterns/images.</li>
+	</ul>
+	</li>
+<li><b>Color Blindness</b><br>
+	Do not use color as the only way to express information.
+	</li>
+<li><b>Blindness</b><br>
+	To assist blind people in accessing OpenOffice.org we have to provide
+	alternatives to the graphical user interface.  These can be
+	<ul>
+	<li>Speech output uses speech synthesis to give a textual
+	  representation of everything visible on the screen.</li>
+	<li>Braille display</li>
+	</ul>
+	</li>
+<li><b>Hard of Hearing / Deafness</b><br>
+	<ul>
+	<li>Closed captioning for providing textual representation of
+	  spoken information.</li>
+	<li>Visible representation of audio signals.</li>
+	</ul>
+	</li>
+<li><b>Mobility Impairments</b><br>
+	Caused by diseases like Parkin-son's disease or multiple sclerosis
+	or physical injuries resulting loss of limbs there is a wide
+	variety of mobility impairments.  People can be assisted by:
+	<ul>
+	<li>Alternative pointing devices like foot operated mice or eye
+	  trackers.</li>
+	<li>On screen keyboard that is operated with the mouse or
+	  alternative pointing device.</li>
+	<li>Speech recognition.</li>
+	<li>Sticky keys provide functionality similar to shift locking for
+	keys like control and alternate.  This enables the user to operate
+	the keyboard with a single finger.</li>
+	</ul>
+	</li>
+
+<li><b>Cognitive Impairments or Learning Disabilities</b><br>
+	Make the (G)UI clear and easy to understand.  Provide help files
+	and documentation (training?).  
+	</li>
+<li><b>Seizure Disorders</b><br>
+	Make flashing, rotating, or moving displays adjustable or provide
+	a switch to disable them.
+	</li>
+</ul>
+</p>
+
+<p>See these lists of the different <a
+href="http://developer.gnome.org/projects/gap/disability-types.html"
+title="List of the different types of disabilities from Gnome"
+>types of disabilities</a> and <a 
+href="http://developer.gnome.org/projects/gap/at-types.html"
+title="Different types of assistive technology from Gnome"
+>assistive technology</a> from the Gnome Accessibility Project for
+more details.</p>
+</body>
+</html>
+

Propchange: incubator/ooo/ooo-site/trunk/content/ui/accessibility/disabilities.html
------------------------------------------------------------------------------
    svn:eol-style = native

Added: incubator/ooo/ooo-site/trunk/content/ui/accessibility/docrep-guidelines.html
URL: http://svn.apache.org/viewvc/incubator/ooo/ooo-site/trunk/content/ui/accessibility/docrep-guidelines.html?rev=1206938&view=auto
==============================================================================
--- incubator/ooo/ooo-site/trunk/content/ui/accessibility/docrep-guidelines.html (added)
+++ incubator/ooo/ooo-site/trunk/content/ui/accessibility/docrep-guidelines.html Mon Nov 28 00:36:55 2011
@@ -0,0 +1,121 @@
+<html><head>
+<meta HTTP-EQUIV="content-type" CONTENT="text/html; charset=UTF-8">
+</head>
+<body>
+<h2>Document representation guidelines</h2>
+
+<p><em>Last modification on October 31st 2001.</em></p>
+
+<p>The following list contains a set of guidelines for the representation of
+StarOffice/OpenOffice.org documents with the UNO Accessibility API (UAA).
+The intention of these guidelines is to define--in an application unspecific
+way--what kind of information of a document should expose over the UAA.  It
+thus complements the syntactic specification made by the actual UAA
+definition.</p>
+
+<p>It is not the goal of these guidelines to give a detailed description of
+how to represent documents of the individual applications.  That is done at
+another place.
+</p>
+
+<ol>
+<li><b>View based approach</b><br>
+<p>In order to let people that use different interfaces--for example the
+OpenOffice.org GUI or a Braille display--help each other with working on a
+document all of them need to have access to an <em>equivalent</em>
+representation of that document.  We think that the best way to achieve this
+goal is to use the current GUI as a reference and to expose all information
+over the UAA that is available over the GUI.</p>
+
+<p>We are, of course, aware of the fact that the information available over
+the UAA will not be completely equivalent to that available over the GUI.
+Content of graphical objects for example can be exposed only rudimentary.</p>
+
+<p>This approach is called view based as opposed to a structure or content
+based approach that would focus not on the graphical appearance on the screen,
+but on the structure of a document's content.</p>
+
+<p>Consequences of employing the view based approach are for instance that in
+a Writer document a text paragraph may be split into several portions
+according to its layout on the screen.  Another example is the exposure of how
+text is broken into lines.</p>
+
+<p>A further reason to favor the view based approach over the content based
+one is the better consistency with the WYSIWYG paradigm.</p>
+<br>
+</li>
+
+
+<li><b>Keep it simple</b><br>
+
+<p>The idea behind this rule is to keep the <em>structure</em> of the UAA
+document representation as simple as possible while at the same time give
+access to as much of a document's semantical <em>content</em> as possible.
+One way to achieve that is to remove nodes from the representation tree that
+expose no content by themselves but serve only as container for other
+objects.  Such container nodes should be used only in selected places.</p>
+
+<p>The reason for this is a pragmatically one.  Current AT devices can't cope
+with information with a structure that is overly complex.  Moreover, no AT
+vendor will invest much time and money into supporting an API that differs too
+much from their current source of information.</p>
+<br></li>
+
+
+<li><b>Don't represent objects that lie completely off-screen</b><br>
+
+<p>There are two reasons for this rule.  The first one is to keep the document
+representation consistent with what is visible on the screen.  If document
+parts not visible on the screen where given access to via the UAA each AT
+device had to figure out on its own what parts are visible and shall be
+exposed to the user and which parts to hold back.</p>
+
+<p>The second reason is the reduction of the amount of data that has to be
+transmitted from application to AT.  This point is mainly relevant when
+application and AT are not running on the same computer.  When exposing the
+whole document over the UAA the AT would have to probe a lot of objects in
+order to determine the visible ones.</p>
+
+<p>There is one exception to not represent off-screen objects.  Calc tables
+will give access to all their cells at once regardless of whether they are
+on- or off-screen.  There are again two reasons for this.  The first is
+consistency with existing implementations of the AccessibleTable interface
+like the javax.swing.JTable.AccessibleJTable class.  The second reason has
+to do with cell indices.  When only the visible cells would be represented
+scrolling the document would result in each cell getting new indices--relative
+to the upper left visible cell--assigned.  This would render using indices
+virtually useless.  Representing all cells leads to indices that remain
+unchanged by scrolling.</p>
+
+<p>There still remains the issue of partially visible document parts.  Some,
+like text paragraphs, may be split into on- and off-screen parts.  If that
+is not possible partially visible objects are handled exactly like
+completely visible objects.</p>
+
+<p>Use the VISIBLE and SHOWING states to appropriately mark objects.  If
+they are completely or partially visible on the screen they are VISIBLE
+<em>and</em> SHOWING.  Objects contained in the UAA representation tree,
+that lie outside the visible area are marked as VISIBLE <em>but not</em>
+SHOWING.</p> <br></li>
+
+<li><b>Don't represent hidden objects</b><br> 
+
+<p>This is very similar to the previous rule.  Objects that have been
+actively marked as hidden are not visible on the screen and therefore are
+not represented by the API.</p> <br></li>
+
+<li><b>Do not represent the cursor position explicitly beyond the means of
+AccessibleText</b><br>
+
+<p>The cursor position, i.e. the position at which text typed on the
+keyboard will be inserted into a document, has not to be explicitely exposed
+by the UAA e.g. by providing special AccessibleAction objects.  It is taken
+care of by sending events with every change of the cursor position, which
+contain information about the AccessibleText object which contains the
+cursor.  This object can then be queried for the caret position.</p>
+
+</li>
+</ol>
+</body>
+</html>
+

Propchange: incubator/ooo/ooo-site/trunk/content/ui/accessibility/docrep-guidelines.html
------------------------------------------------------------------------------
    svn:eol-style = native

Added: incubator/ooo/ooo-site/trunk/content/ui/accessibility/document_representation_writer.html
URL: http://svn.apache.org/viewvc/incubator/ooo/ooo-site/trunk/content/ui/accessibility/document_representation_writer.html?rev=1206938&view=auto
==============================================================================
--- incubator/ooo/ooo-site/trunk/content/ui/accessibility/document_representation_writer.html (added)
+++ incubator/ooo/ooo-site/trunk/content/ui/accessibility/document_representation_writer.html Mon Nov 28 00:36:55 2011
@@ -0,0 +1,222 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
+<HTML>
+<HEAD>
+	<META HTTP-EQUIV=3D"CONTENT-TYPE" CONTENT=3D"text/html; charset=3Diso-8=
+859-1">
+	<TITLE></TITLE>
+	<!-- Changed by: Andre Fischer, 21-Sep-2001 -->
+	<META NAME=3D"GENERATOR" CONTENT=3D"StarOffice 6.0  (Solaris Sparc)">
+	<META NAME=3D"AUTHOR" CONTENT=3D"Michael Brauer">
+	<META NAME=3D"CREATED" CONTENT=3D"20010919;8143700">
+	<META NAME=3D"CHANGEDBY" CONTENT=3D"Michael Brauer">
+	<META NAME=3D"CHANGED" CONTENT=3D"20010921;16293200">
+	<STYLE>
+	<!--
+		@page { size: 21cm 29.7cm; margin-left: 3.18cm; margin-right: 3.18cm; =
+margin-top: 2.54cm; margin-bottom: 2.54cm }
+		P { margin-bottom: 0.21cm; font-family: "Frutiger Roman", "Arial" }
+		H1 { margin-bottom: 0.21cm; font-family: "Albany", sans-serif; font-si=
+ze: 16pt }
+		P.documenttype { font-size: 24pt; font-weight: bold }
+		P.companyname { margin-bottom: 0cm; color: #00a6ff; font-family: "Frut=
+iger-Bold", "Arial", "Helvetica"; font-size: 36pt; font-weight: bold; te=
+xt-align: right }
+		H2 { margin-bottom: 0.21cm; font-family: "Albany", sans-serif; font-si=
+ze: 14pt; font-style: italic }
+	-->
+	</STYLE>
+</HEAD>
+<BODY>
+<TABLE WIDTH=3D100% BORDER=3D0 CELLPADDING=3D0 CELLSPACING=3D0 STYLE=3D"=
+page-break-before: always; page-break-inside: avoid">
+	<COL WIDTH=3D128*>
+	<COL WIDTH=3D128*>
+	<THEAD>
+		<TR VALIGN=3DTOP>
+			<TD WIDTH=3D50%>
+				<P CLASS=3D"documenttype"><B>Draft</B></P>
+			</TD>
+			<TD WIDTH=3D50%>
+				<P CLASS=3D"companyname">Star Office</P>
+			</TD>
+		</TR>
+	</THEAD>
+</TABLE>
+<H1>Proposal for an Accessibility API in StarOffice Writer</H1>
+<H2>Introduction</H2>
+<P>In the following proposal it is assumed that StarOffice's
+Accessibility API is based on the Java Accessibility API. For that
+reason, it is very often referred to classes and interfaces of that
+API. The classes and interfaces mentioned are:</P>
+<UL>
+	<LI><P>class AccessibleContext: An object (for instance a button)
+	may support an interface Accessible. In this case, one can retrieve
+	an object of class AccessibleContext from the object. An object of
+	class AccessibleContext has some methods that support Assistive
+	Technology tools, for instance by assigning a role and a description
+	to the original object. The AccessibleContext objects for a certain
+	dialog, or for a document, might be arranged to a tree there each
+	AccessibleContext is a node of this tree. The structure of such
+	trees is discussed below.</P>
+	<LI><P>AccessibleEditableText is an interface that offers access to
+	text as well as methods to modify the text. It might be supported by
+	objects of class AccessibleContext.</P>
+	<LI><P>AccessibleComponent is an interface that might be supported
+	by an AccessibleContext and describes the position and size of an
+	object that is displayed on the screen relative to the parent
+	AccessibleContext.</P>
+	<LI><P>AccessibleAction is an interface that might be supported by
+	an AccessibleContext. It offers the possibility to trigger (custom)
+	operations that are applied to that object.</P>
+</UL>
+<P>The proposal for an Accessibility API  for StarOffice Writer
+described in this document is still incomplete. It mainly covers the
+following areas:</P>
+<UL>
+	<LI><P>The representation of the current text position (i.e. the
+	text cursor).</P>
+	<LI><P>The conflict between an AccessibleContext tree that
+	represents the current view and an AccessibleContext tree that
+	represents the whole document based on its logical structure.</P>
+</UL>
+<H2>The Text Cursor</H2>
+<P>In current word processors as well as in simple text editors,
+there is the concept of a text cursor. That is a position there any
+insertion, deletion, change, etc. takes place. These operations can
+be triggered for instance by a key stroke or by selecting a menu
+item.=20
+</P>
+<P>Within a tree of AccessibleContexts it's quite difficult to
+represent a text cursor. Even if the leafs of an AccessibleContext
+tree would be characters (regardless whether this is sensible), there
+would not be a position between to leafs. It also seems not to be
+convenient that the text cursor is an AccessibleContext itself. The
+result would be that every move of the text cursor would change the
+AccessibleContext tree.</P>
+<P>However, the problem is already solved within the
+AccessibleEditableText interface. This interface on the one hand
+offers methods to retrieve a word, character or sentence at a certain
+character position within some text. On the other hand, it offers
+methods to set and get a caret and a selection within the text, where
+a caret is a selection that has the same character start and end
+position. This is nearly the same as a traditional text cursor,
+except that a text cursor not only denotes a position within a
+paragraph but also a certain paragraph. In contrast to this, the
+AccessibleEditableText does not have the concept of paragraphs at
+all.</P>
+<P>To be able to use the AccessibleEditableText interface anyway, one
+has to specify that each paragraph is represented by an=20
+AccessibleEditableText interface of its own. Disregarding things like
+text boxes and footnotes, paragraphs in this case are leafs of the
+AccessibleContext tree that additionally support the
+AccessibleEditableText interface.</P>
+<P>However, what's still missing is a way to mimic the paragraph
+position of a traditional text cursor. This could be done by making
+it possible to give a focus not only to controls but also to
+paragraphs. In other words, if there is not eventually a text box or
+some other kind of non paragraph object selected, there always is one
+paragraph that has the focus. Any operation within the paragraph is
+done by the  AccessibleEditableText interface. Or in other words
+again, within the Accessibility API the paragraph position of a
+traditional text cursor is represented by assigning the focus the
+paragraphs itself while its character position is mapped to the caret
+of the paragraph's  AccessibleEditableText interface.</P>
+<H2>The visual and the logical AccessibleContext Tree</H2>
+<P>A tree of AccessibleContext either may represent a document's
+logical structure or its representation as printed or displayed on a
+screen. Moreover, it may either represent a full document or just a
+part of it.</P>
+<P>Having the logical tree of the whole document on the one hand
+makes powerful AT tools possible, on the other hand it might be the
+case that these tools have to be powerful to be able to handle the
+large amount of information they get. However, to make such tools
+possible, a tree like this should be existing.</P>
+<P>Another tree that seems to be necessary is a tree that represents
+the current view of the document as displayed on the screen. This has
+several reasons. First of all, there might be situations where one
+can see the screen view, but needs AT tools for input or to get
+additional information. In this case, it seems to be an advantage if
+the AT tool may operate on exactly the same data that is displayed on
+the screen.</P>
+<P>Another reason is that this tree simplifies the interoperation
+between traditional UI operations and and the AccessibleContext tree.
+ It's hard to image how an UI operation could be applied to some data
+if these data is not visible, but its also seems to be impossible to
+make any operation that can be triggered using the UI available to
+the Accessibility API, too.=20
+</P>
+<P>Last but not least an AccessibleContext tree bases on the current
+screen view is required if a blind and a non blind shall have a look
+at the same document. For instance, if a blind wants to know what is
+shown in an image it's required that he can make the image visible on
+the screen. Moreover, it seems to be convenient that he can describe
+the position of the image on the screen instead of having to describe
+where it is located in the logical tree of the document.</P>
+<P>Another possibility, having a tree that represents only a part of
+the document, seems to be not convenient, because this would be a sub
+tree of the whole document only. A tree that represents the whole
+document but in the way it is displayed at the screen or printed
+might be more convenient. However, having the possibility to navigate
+through the document like it is done on the screen should be
+sufficient. Therefor, I pay no attention to these to possibilities
+here. For convenience, the tree that represents the whole document
+logically is called logical tree in this document. The tree that
+represents the document's view on the screen is called screen tree.</P>
+<P>As mentioned above, it seems to be necessary that using the
+Accessibility API makes it further possible to use the UI. Many UI
+operations take the current text cursor position into account. Using
+the above representation of the text cursor as a focus of a paragraph
+and a caret in this paragraph, this is no problem for the screen
+tree. The only thing that has to be ensured is that the state of the
+tree and the text cursor are synchronized. This in fact, should be
+the expected behavior anyway.</P>
+<P>Making the the logical tree and the UI working together is not
+much harder anyway. A prerequisite for this is that there is exactly
+one AccessibleContext for any object that can be contained in the
+logical as well as in  the screen tree, for instance for a paragraph.
+In other words, one and the same AccessibleContext has to be
+contained in the logical as well as the screen tree if it belongs to
+the same object, for instance a paragraph. What's missing then is a
+possibility to assign the focus to a certain paragraph. This most
+probably can be  done by the AccessibleComponent interface (if one
+specifies that it is available for AcessibleContexts that are no
+visible currently, too), or it can be implemented by an
+AccessibleAction. Assigning the focus to an AccessibleContext has to
+make the paragraph visible on the screen. This way, it's possible to
+navigate and operate on the logical tree, but also to use the UI by
+assigning the focus to a certain paragraph. The screen tree in this
+case might offer an additional help, but of course it's not required
+to use it.</P>
+<H2>Other Objects, Like Tables Or Drawings</H2>
+<P>The above proposal can be extended to other objects like tables or
+drawings by specifying that these objects, or the objects they
+consist of, may get a focus, too.</P>
+<H2>The Logical Tree</H2>
+<P>It's quite obvious that the logical tree should reflect the
+chapter/sub section structure of a document. The remaining issue is
+how detailed the tree should be. It seems to be sensible that the
+tree should contain any object that may get the focus and that might
+get visible.</P>
+<H2>The Screen Tree</H2>
+<P>The structure the screen tree should have is not as obvious as the
+one of the logical tree. One possibility might be to have a root that
+corresponds to the visible area of the document. The visible
+paragraphs might be children of the root directly. But it also might
+be a solution that the root contains a body, a header, a footer and a
+footnote area as children, where any of these areas is optional, and
+that these areas contain the visible paragraphs. However, there seems
+to be no reason to include nodes for chapters or sub sections into
+the screen tree. The screen tree and the logical tree are tied as
+close together that these information can be obtained from the
+logical tree at any time.</P>
+<P>One issue regarding the screen tree is the fact that a paragraph
+might be visible partially only or might be split by a page break.
+The first problem might be addresses by an enhanced
+AccessibleComponent interface that provides information which parts
+of the paragraph are visible. The second problem might be addressed
+by having a list of AccessibleComponents instead of a single one.</P>
+<P><BR><BR>
+</P>
+</BODY>
+</HTML>
+

Propchange: incubator/ooo/ooo-site/trunk/content/ui/accessibility/document_representation_writer.html
------------------------------------------------------------------------------
    svn:eol-style = native

Added: incubator/ooo/ooo-site/trunk/content/ui/accessibility/index.html
URL: http://svn.apache.org/viewvc/incubator/ooo/ooo-site/trunk/content/ui/accessibility/index.html?rev=1206938&view=auto
==============================================================================
--- incubator/ooo/ooo-site/trunk/content/ui/accessibility/index.html (added)
+++ incubator/ooo/ooo-site/trunk/content/ui/accessibility/index.html Mon Nov 28 00:36:55 2011
@@ -0,0 +1,108 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+<HTML>
+<HEAD>
+	<META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=windows-1252">
+	<TITLE>OpenOffice.org Accessibility</TITLE>
+	<META NAME="GENERATOR" CONTENT="StarOffice 8  (Win32)">
+	<META NAME="CREATED" CONTENT="20061031;16330616">
+	<META NAME="CHANGED" CONTENT="20061031;17014198">
+</HEAD>
+<BODY LANG="en-US" DIR="LTR">
+  <h1>OpenOffice.org Accessibility Project</h1>
+  <h3>Project Goal</h3>
+  <P>Making OpenOffice.org accessible means to make it usable by people
+regardless of their disabilities. 
+</P>
+  <P>There are various Accessibility aspects: Keyboard navigation,
+scheming, AT support and much more. 
+</P>
+  <P>Details can be found here:
+<A HREF="http://ui.openoffice.org/accessibility/whitepaper.html">http://ui.openoffice.org/accessibility/whitepaper.html</A>.
+</P>
+  <h3>Making OpenOffice.org accessible</h3>
+  <P>There are three strategies to make OpenOffice.org accessible: 
+</P>
+  <UL>
+   <LI><B>Keyboard navigation</B>
+   <P>Allow the user to control OpenOffice.org completely with the
+	keyboard so that the use of a mouse is not necessary.</P>
+   <P>OpenOffice.org is already controllable in large parts via the
+	keyboard. As open task remain for instance switching into and
+	between dialogs and activating and deactivating OLE objects.</P>
+   <LI><B>Visual and keyboard enhancements</B>
+   <P>Keyboard enhancements comprise the support of keyboard like input
+	devices that differ from standard keyboards. This support is covered
+	by the operating systems that OpenOffice.org runs on.</P>
+   <P>Visual enhancements like enlarged and clearer fonts are already
+	possible with the existing OpenOffice.org.</P>
+   <LI><B>Assistive technology</B>
+   <P>Assistive technology comprise such different devices like screen
+	readers and braille terminals. There are several APIs that serve as
+	common abstraction of the various AT input and output devices. We
+	are aiming at the Java Accessibility API as the only truly operating
+	system independent member of that group while at the same time
+	keeping an eye on the Gnome Accessibility API. Both are very similar
+	in the way they represent an application and the kind of information
+	they provide for the individual parts of the (G)UI.</P>
+   <P>Our approach of supporting AT with the UNO Accessibility API is
+	documented <A HREF="at-support.html">here</A> in detail.</P>
+	<P>A list of AT known to work with OpenOffice.org is maintained on
+	<A HREF="http://wiki.services.openoffice.org/wiki/Accessibility">http://wiki.services.openoffice.org/wiki/Accessibility</A>.</P>
+</UL>
+  <h3><a name="participation"></a>Participation</h3>
+  <P>To participate in the work of making OpenOffice.org accessible,
+ask questions, or make comments you can use the
+<B>accessibility@ui.openoffice.org</B> mailing list.</P>
+  <h3>Links</h3>
+  <UL>
+   <LI>Local links: 
+   <UL>
+    <LI><A HREF="whitepaper.html">Accessibility
+		White Paper</A>
+    <LI><A HREF="disabilities.html">List
+		of Disabilities and Assistive Technology</A>
+    <LI><A HREF="unoapi.html">The UNO
+		Accessibility API (UAA)</A>
+    <LI><A HREF="at-support.html">How
+		OpenOffice.org supports Assistive Technology through the UAA</A>
+    <LI><A HREF="AWB.html">Test tool: the
+		Accessibility Work Bench</A>
+   </UL>
+   <LI>APIs: 
+   <UL>
+    <LI>UNO Accessibility API:
+<A HREF="http://ui.openoffice.org/accessibility/unoapi.html">http://ui.openoffice.org/accessibility/unoapi.html</A>
+   </UL>
+   <LI>Java Accessibility (version 1.4):
+<A HREF="http://java.sun.com/j2se/1.4/docs/guide/access/">http://java.sun.com/j2se/1.4/docs/guide/access/</A>
+   <LI>The Gnome Accessibility Project:
+<A HREF="http://developer.gnome.org/projects/gap/">http://developer.gnome.org/projects/gap/</A>
+   <LI>Laws regarding accessibility: 
+   <UL>
+    <LI>List of legal issues in different
+		countries from the Gnome Accessibility Project:
+<A HREF="http://developer.gnome.org/projects/gap/laws.html">http://developer.gnome.org/projects/gap/laws.html</A>
+   </UL>
+   <LI>Home page of section 508:
+<A HREF="http://www.usdoj.gov/crt/508/508home.html">http://www.usdoj.gov/crt/508/508home.html</A>
+   <LI>Section 508 software analysis:
+<A HREF="http://www.usdoj.gov/crt/508/report/software.htm">http://www.usdoj.gov/crt/508/report/software.htm</A>
+   <LI>Guidlines for writing accessible
+	documents: 
+   <UL>
+    <LI>Guidlines from the W3 Consortium:
+<A HREF="http://www.w3.org/TR/WCAG20/">http://www.w3.org/TR/WCAG20/</A>
+   </UL>
+   <LI>HTML related page from IBM:
+<A HREF="http://www-3.ibm.com/able/accessweb.html">http://www-3.ibm.com/able/accessweb.html</A>
+   <LI>'Bobby' is a tool for HTML page authors that can check
+	existing pages: <A HREF="http://www.cast.org/bobby">http://www.cast.org/bobby</A>
+  </UL>
+  <P><BR>
+  </P>
+  <h4>Related Project</h4>
+  <ul>
+   <li><a href="http://ux.openoffice.org/">OpenOffice.org User Experience Project</a>
+  </ul>
+ </BODY>
+</HTML>
\ No newline at end of file

Propchange: incubator/ooo/ooo-site/trunk/content/ui/accessibility/index.html
------------------------------------------------------------------------------
    svn:eol-style = native

Added: incubator/ooo/ooo-site/trunk/content/ui/accessibility/proposal-calc.html
URL: http://svn.apache.org/viewvc/incubator/ooo/ooo-site/trunk/content/ui/accessibility/proposal-calc.html?rev=1206938&view=auto
==============================================================================
--- incubator/ooo/ooo-site/trunk/content/ui/accessibility/proposal-calc.html (added)
+++ incubator/ooo/ooo-site/trunk/content/ui/accessibility/proposal-calc.html Mon Nov 28 00:36:55 2011
@@ -0,0 +1,136 @@
+<html>
+
+<head>
+<meta HTTP-EQUIV="content-type" CONTENT="text/html; charset=UTF-8">
+</head>
+<body>
+
+<h2>Spreadsheet document Accessibility</h2>
+
+<p>Proposal</p>
+
+<p>by Sascha Ballach (<a href="mailto:Sascha.Ballach@sun.com"
+
+title="Mail address of Sascha Ballach">Sascha.Ballach@sun.com</a>),<br>
+
+last modification on November 19th 2001</p>
+
+
+
+
+
+<h3>1. Introduction</h3>
+
+
+
+<p>This paper describes how documents of the StarOffice/OpenOffice.org
+
+Calc application can be made accessible by using the UNO
+
+Accessibility API (UAA).</p>
+
+
+
+
+
+<h3>2. General</h3>
+
+
+
+<p>Spreadsheet documents consist of one ore more tables. Each table contains
+
+a lot of cells and can contain many other objects. There are many ways to
+
+access this things.</p>
+
+<p>The cells can you access by the position or with an index.</p>
+
+<p>To access the other objects you have some possible ways. On the one hand
+
+you can get this objects with the navigator. On the other hand you can get
+
+this objects as childs of the cell or table were the anchor is.</p>
+
+<p>To make the Data Pilot and Database Ranges more accessible we should extend
+
+the navigator.</p>
+
+
+
+<h3>3. specific problems</h3>
+
+
+
+<h4>3.1. notes</h4>
+
+<p>The notes are handled as the description of a cell. It does not matter
+
+whether the note is showed or not, the description is given always.</p>
+
+
+
+<h4>3.2. merged and matrix cells</h4>
+
+<p>With the methods getAccessibleColumnExtentAt and getAccessibleRowExtentAt I
+
+will make the dimension of merged cells accessible. The dimension of matrix
+
+cells is only to find out while going from cell to cell and have a look at
+
+the formula. This is the same way a not disabled person it does.</p>
+
+
+
+<h4>3.3. column and row description</h4>
+
+<p>At the moment it is not possible to give the column or the row a description.
+
+If the user asks for the description he will get in the first step the name of
+
+the column/row and he can not change the description.</p>
+
+
+
+<h4>3.4. Outlining</h4>
+
+<p>At the moment I have no idea how to make outlining accessible. Perhaps it is
+
+enough to use the current menu structure.</p>
+
+
+
+<h4>3.5. Index range</h4>
+
+<p>The index range is no problem at the moment, but if we change the row and
+
+column count (and we will change this) we could need a bigger range for the
+
+index.</p>
+
+
+
+<h4>3.6. Shapes</h4>
+
+<p>Shapes are children of the root object which also contains the currently
+
+viewed table. We have to handle this in this way, because otherwise it would
+
+not be possible to select all shapes. To represent the anchor of a shape there
+
+is a realtion between the shape and the cell or table with the anchor.</p>
+
+
+
+<h4>3.7. Formulas</h4>
+
+<p>Formulas are only accessible by the edit line or in the edit mode of the
+cell. There is the same behaviour for not disabled people.</p>
+
+
+
+
+
+</body>
+
+</html>
+

Propchange: incubator/ooo/ooo-site/trunk/content/ui/accessibility/proposal-calc.html
------------------------------------------------------------------------------
    svn:eol-style = native

Propchange: incubator/ooo/ooo-site/trunk/content/ui/accessibility/proposal-calc.html
------------------------------------------------------------------------------
    svn:executable = *

Added: incubator/ooo/ooo-site/trunk/content/ui/accessibility/proposal-chart.html
URL: http://svn.apache.org/viewvc/incubator/ooo/ooo-site/trunk/content/ui/accessibility/proposal-chart.html?rev=1206938&view=auto
==============================================================================
--- incubator/ooo/ooo-site/trunk/content/ui/accessibility/proposal-chart.html (added)
+++ incubator/ooo/ooo-site/trunk/content/ui/accessibility/proposal-chart.html Mon Nov 28 00:36:55 2011
@@ -0,0 +1,179 @@
+<html><head>
+<meta HTTP-EQUIV="content-type" CONTENT="text/html; charset=UTF-8">
+</head>
+<body>
+<h2>Chart Accessibility</h2>
+<p>Proposal</p>
+<p>by Bj&ouml;rn Milcke (<a href="mailto:Bjoern.Milcke@Sun.COM" title="Mail
+address of Bj&ouml;rn Milcke">Bjoern.Milcke@Sun.COM</a>),<br> last modification
+on March 5th 2002</p>
+
+<!-- ---------------------------------------- -->
+<h3>1. Introduction</h3>
+
+<p>This paper describes how documents of the StarOffice/OpenOffice.org Chart
+application can be made accessible by using the UNO Accessibility API (UAA).</p>
+
+<!-- ---------------------------------------- -->
+<h3>2. Chart Documents</h3>
+
+<p>In contrast to other applications, a chart document has a relatively fixed
+structure.  For most objects in a chart you always have at most one instance.
+For example, there may only be one main title object and one legend.  Only the
+number of data series and data points inside of series may change, which depends
+directly on the dimension of the input data.</p>
+
+<p>There is only one page in a chart.  On this page there are the following
+top level objects:</p>
+<ul>
+ <li>Titles (main title, subtitle, axis titles)</li>
+ <li>Legend</li>
+ <li>Diagram</li>
+ <li>Additional shapes (see <a href="#add-shapes">section 4</a>)</li>
+</ul>
+<p>The page's background color is determined by the chart area object, which is
+the object that you can select via the GUI to format the background of the
+entire space a chart document occupies.</p>
+
+<p>The Diagram is the object containing the actual plot.  In three-dimensional
+charts the diagram is a scene object.  There are four kinds of sub-objects in
+the diagram:</p>
+<ul>
+ <li>Series representing parts of the data (see <a href="#series">section 3</a>)</li>
+ <li>Axes (primary x/y/z axis, secondary x/y axis)</li>
+ <li>Grids (major and minor grids)</li>
+ <li>Wall, and floor for three-dimensional charts</li>
+</ul>
+
+<p>The number of objects we are dealing with here is limited to a small constant
+for all objects except the series.  These can vary in number depending on the
+size of the input data; however usually, this number should also be small.
+Having more than ten, or so, series usually doesn't make much sense.  In
+contrast, the series themselves can contain a lot of data points.  This might
+become a problem for AT (Assistive Technology) tool.  We will discuss this
+issue in the following section.</p>
+
+<!-- ---------------------------------------- -->
+<h3><a name="series">3. Data Series and Data Points</a></h3>
+
+<p>As stated before, the number of series usually is small.  So, we assume not
+having problems here.  However, the number of data points contained in a series
+may be huge, and although you may not be able to really distinguish all points
+from each other on a screen, they are all visible in the current window, thus
+have to be made accessible.</p>
+
+<p>Consider a chart where you have five series, each representing 2,000 data
+points displayed as little symbols.  You can select every of those points
+(e.g. via the keyboard) and give it a different formatting, thus you should also
+provide them as objects in the document tree for getting notified on selection.
+As a result we would get 10,000 objects in the tree for those objects.  This
+will consume a lot of time and also memory.  Maybe a tool might even crash when
+getting such a lot of nodes, because normally you do not have so many objects in
+a document that are all visible at the same time (especially in dialogs, for
+which most tools were initially designed).  There are several solutions to this
+problem, which we want to discuss next.</p>
+
+<h4>Assume that AT-Tools are Clever</h4>
+
+<p>An AT-tool may feel free to query the number of children and accessible
+object has.  If it turns out that this number is quite high (according to some
+threshold), the tool could simply not request those objects.  Even on rendering,
+those objects could be omitted, because their bounding boxes must all lie in the
+bounding box of the parent element.</p>
+
+<p>However, if a user travels down the document to a series, the tool would most
+probably load all children to offer them to the user.  Alternatively the tool
+could just state how many children there are, and the user could select the
+<em>n</em><sup>th</sup> child without knowing what this child <em>looks</em>
+like.</p>
+
+<p>The question here mainly is, if AT-tools will be enhanced when the
+requirements increase for using StarOffice/OpenOffice.org.  As this does not lie
+in our hands, this way has a certain risk.</p>
+
+<h4>Offer only those Data Points that have their Own Attributes</h4>
+
+<p>When you create a chart from scratch, all data points have no own attributes.
+Instead they inherit their appearance from the series.  A user can select a data
+point and apply different properties to it.  Internally, there is a list of all
+data points that differ from the default, i.e., have been modified by a user.
+The number of modified data points usually is also small.</p>
+
+<p>This way, a user accessing a document via an AT-tool could get information
+about all data points that are differently formatted.  For example, if a series
+has a blue fill color, and one data point is made red to underline its
+importance, the user would have access to it.  However, the user would not be
+able to select an unformatted data point to apply a different color herself.</p>
+
+<h4>Do not offer Data Points at All</h4>
+
+<p>The data points are usually not formatted differently from the series.  And
+even if some points are differently formatted, the question remains if a user is
+interested in that.  One important property of a data point is its value.  But
+the value can be found in the underlying data table, which is also accessible.
+So we could generally ignore data points.</p>
+
+<p>The only downside of this is that you can select data points via the GUI,
+e.g., the keyboard.  When doing so you would get an object that is not
+accessible from the view.</p>
+
+<h4>Offer Data Points dependent on Chart Type</h4>
+
+<p>If you take for example pie charts, you will notice that there will usually
+not be too many data points, otherwise you could not really interpret this chart
+visually (which is the main purpose of a chart).  And also bar charts, mostly
+used in business graphics, do not have too many bars.</p>
+
+<p>The most prominent examples for charts that may represent huge amount of
+data, are line charts and xy-charts (scatter charts).  Those two chart types
+also have subtypes that contain just the lines and no symbols.  In this case
+there simply do not exist any data points.  Thus, the problematic situation is
+(under our previous assumptions) having a line- or scatter chart using symbols
+for a lot of data points.</p>
+
+<p>One solution (which in fact solves the problem just under the assumptions
+made) would be not to offer any data points for certain chart types, namely
+line- and scatter charts (and maybe radar charts).</p>
+
+<h4>Offer Data Points dependent on the Quantity</h4>
+
+<p>As we can never be sure that there are no bar charts with thousands of bars,
+the previous approach may fail.  So we could use a heuristic that children are
+only created, if their number is smaller than a given constant threshold.  This
+way we would be on the safe side.  We would also have no problems for all types
+of charts having only a small number of data points per series.</p>
+
+<p>A remaining problem would still be the inconsistency, that you could select
+data points via the GUI (the keyboard) but would not get accessible objects from
+the selection.  However, this seems to me the most promising approach at the
+moment.</p>
+
+<!-- ---------------------------------------- -->
+<h3><a name ="add-shapes">4. Additional Shapes</a></h3>
+
+<p>You can add additional shapes to a chart.  When being inserted via the
+clipboard those shapes are always meta-files or bitmaps.  These shapes can be
+treated the same way as shapes in the Draw/Impress.  In other words, we can get
+an XShape from the drawing layer that supports all necessary accessibility
+capabilities.</p>
+
+<!-- ---------------------------------------- -->
+<h3>4. Visibility</h3>
+
+<p>The tree of accessible objects is always constructed of the objects that are
+in the current scope of the screen.  Charts may only be OLE objects, and the
+view for an OLE object is only created when it is entered in <em>In-Place
+mode</em>.  On activation the OLE-object is moved such that it is completely
+visible, unless its size exceeds the size of the window.  This is the only
+(rare) situation when not all objects of a chart may be visible.</p>
+
+<p>Apart from that, consider a bar chart where the rightmost bar is not in the
+current scope.  I think it doesn't make much sense to offer all data series, but
+one series has one data point less than the others, just because it is not
+visible.</p>
+
+<p>Therefore I suggest to always offer the complete tree of objects, no matter
+if really everything is visible.</p>
+</body>
+</html>
+

Propchange: incubator/ooo/ooo-site/trunk/content/ui/accessibility/proposal-chart.html
------------------------------------------------------------------------------
    svn:eol-style = native

Added: incubator/ooo/ooo-site/trunk/content/ui/accessibility/proposal-impress.html
URL: http://svn.apache.org/viewvc/incubator/ooo/ooo-site/trunk/content/ui/accessibility/proposal-impress.html?rev=1206938&view=auto
==============================================================================
--- incubator/ooo/ooo-site/trunk/content/ui/accessibility/proposal-impress.html (added)
+++ incubator/ooo/ooo-site/trunk/content/ui/accessibility/proposal-impress.html Mon Nov 28 00:36:55 2011
@@ -0,0 +1,235 @@
+<html><head>
+<meta HTTP-EQUIV="content-type" CONTENT="text/html; charset=UTF-8">
+</head>
+<body>
+<h2>Impress and Draw Accessibility</h2>
+<p>Proposal</p>
+<p>by Andre Fischer (<a href="mailto:andre.w.fischer@sun.com" 
+title="Mail address of Andre Fischer">andre.w.fischer@sun.com</a>),<br>
+last modification on November 11th 2001</p>
+
+
+<h3>1. Introduction</h3>
+
+<p>This paper describes how documents of the StarOffice/OpenOffice.org
+Impress and Draw applications can be made accessible by using the UNO
+Accessibility API (UAA).</p>
+
+<p>It will be shown that making Impress accessible can be (largely) reduced
+to making Draw accessible.  This proposal will therefore first give a short
+introduction to Impress documents and then show that mainly Draw pages
+have to be made accessible.</p>
+
+
+<h3>2. Impress Documents</h3>
+
+<p>Impress documents consist of one ore more pages.  Each page can contain a
+number of objects like 
+<ul>
+<li>Outliner objects contain text organized in a hierarchical list.</li>
+<li>Text objects used e.g. for titles.</li>
+<li>Graphical objects like lines, polygons, circles, etc.</li>
+<li>OLE objects</li>
+</ul>
+</p>
+
+<p>Every page of an Impress document is made up of two parts: a drawing page
+and a master page.  There is one drawing page per document page.  Master pages
+are used to specify material that is visible on more than one page and
+therefore can be shared between drawing pages.  A master page can be used for
+example to include the page number, time, date, or author.
+</p>
+
+<p>
+There are six display modes for visualizing an Impress document:
+<ol>
+<li><b>Drawing View</b><br>
+<p>This is the only graphical edit mode.  At any one time there is one document
+page visible on the screen.  Its initial scale is chosen so that the whole
+page fits in the document window.</p></li>
+
+<li><b>Outline View</b><br> <p>The textual content of all pages including
+title and outliner objects is displayed and can be edited in a hierarchical
+list.  It gives an overview of the document's structure and offers an easy
+and non-graphical way to create and modify the document.  The outline view
+is certainly very attractive for users which create an Impress slide show
+via an AT device.</p></li>
+
+<li><b>Slide View</b><br> <p>Display of all pages at once.  This view acts
+as a visual selection tool.  You can browse the whole document for a
+specific page and jump from there into the edit mode.</p></li>
+
+<li><b>Notes View</b><br> <p>This introduces a third kind of page, the notes
+page.  Each notes page is associated to one document page.  It is divided
+into two parts.  The first contains the document page, the second contains a
+list of notes describing the document page.  In this display mode you can
+not edit document pages.</p></li>
+
+<li><b>Handout View</b><br> <p>At the first glance similar to the slide
+view, this mode puts several--defaults to four--document pages onto one
+print page.  It is used to create a printed version of the whole document.
+You can neither edit the pages nor can you jump into the edit mode from
+here.</p></li>
+
+<li><b>Slide Show</b><br> <p>The slide show mode displays all document pages
+full-screen one slide at a time in a consecutive order.  Mouse clicks or
+pressing a key advances to the next page.  No editing in this mode.</p></li>
+</ol> </p>
+
+<p>Only the first mode allows the graphical modification of the document.
+The second lets you change at least the text information.  All but the
+second contain graphical representations of one or more document pages.</p>
+
+<p>As a result we have two different cases.  All modes but the second use
+draw pages for visualizing the document.  This case is handled by making the
+Draw application accessible.  Special handling due to the editing capability of the
+drawing view is not necessary.  The outline view has to be handled
+separately.  The two cases are described in more detail in the next two sections.</p>
+
+
+
+<h3>3. UAA representation of Draw Pages</h3>
+
+<p>The UAA uses a set of interfaces to offer a hierarchical representation of an
+application window.  In the following we will focus on representing one draw
+page.  If there is more than one draw page visible on the screen then each one
+of them is represented by a separate sub-tree.</p>
+
+<p>According to our <a
+href="http://ui.openoffice.org/accessibility/docrep-guidelines.html"
+title="Document representation guidelines">document representation
+guidelines</a> only those objects on a draw page will be represented, that
+are visible at the time of a query.  Both Draw and Impress scale new pages
+so that the whole page fits on the screen.  Therefore, only an active
+rescaling or placing of objects outside the page boundaries will result in
+objects not being represented.</p>
+
+<p>However, there is one exception to the rule to represent only fully or
+partially visible objects.  If a connector links a visible object to one
+object that is currently not visible, this target object will be included
+into the UAA representation.  This is necessary to be able to provide the
+connectors as <code>AccessibleRelation</code> objects.</p>
+
+
+<h4>3.1. Details</h4>
+
+<p>All classes that implement the draw pages and the objects--shapes and OLE
+objects--that can be inserted into a draw page have to be extended to
+support the <code>Accessible</code> service.  Calls to their
+<code>getAccessibleContext</code> method will return references to instances
+of classes that are implemented independently from the draw page and shape
+classes.  That means that the only modification of existing code is needed
+for the support of the <code>XAccessible</code> interface.  All other coding
+can be done independently in another place.</p>
+
+<p>All fully and partially visible objects on a draw page are represented by
+objects that support the <code>AccessibleContext</code> service.  They
+support the additional services <code>AccessibleComponent</code>,
+<code>AccessibleEditableText</code>, <code>AccessibleRole</code>, and
+<code>AccessibleText</code>.  Whether or not the
+<code>AccessibleAction</code> service will be supported has yet to be
+discussed.  If a shape is linked to other shapes via connectors then the
+<code>AccessibleContext</code> object of the shape from which such a link
+originates will return a non empty relation set when the
+<code>getRelationSet</code> method is called.</p>
+
+<p>Each draw page will be represented in a shallow hierarchy.  The root node
+corresponds to the view that is responsible for drawing a document window.
+Its children are the representations of all visible draw pages.  The
+children of each draw page node are the representations of the visible
+shapes on that draw page.</p>
+
+<p>The order of the children of a draw page node depends on the z-order of
+the represented shapes, i.e. the order in which they are painted onto the
+screen: if shape A is painted over by shape B, then shape A comes
+<em>before</em> shape B in the list of children.</p>
+
+<p>The UAA representations of the different view modes described above
+differ only in their second layers: There are a different number of draw
+pages and the draw pages have different geometries.</p>
+
+
+<h4>3.2. Roles, Names, and Descriptions</h4>
+
+<p>The task to assign roles, names, and descriptions to draw shapes is not a
+trivial one.  There is a multitude of shapes which leads to the problem of
+creating meaningful default names and descriptions.
+
+<p>The roles could be taken from a small set like 'View', 'DrawPage', and
+'Shape' that would have essentially one role per layer.  However, this would
+render the role quite useless.  It is preferable to use a larger set of
+roles that gives each type of shape its own role and maybe distinguishes
+even between different kinds of views.  With this an AT can perform special
+actions on certain roles.  A shape's role would be quite similar to a
+shape's default name but because roles are taken from a fixed set (fixed in
+the environment of a given application) while names are free-form strings.
+Roles are therefore better suited to be processed automatically than
+names.</p>
+
+<p>On the first glance naming the objects may seem to be straightforward.
+Simply use the already existing name attribute of the shapes.  The problem
+lies in finding proper default names.  A first and trivial solution is to
+use the shape's type and append a number.</p>
+
+<p>The same holds true with descriptions.  One approach can be to use a
+shape's type and adorn it with a human readable and, more importantly,
+understandable representation of the shape's properties like fill color,
+outline width, or font.</p>
+
+<p>However good the defaults for name and description will be, they will
+never come close to those supplied by the author of a document.  Therefore,
+the author should be more 'encouraged' to do so.  It would be helpful to
+have a special accessibility mode that would--at appropriate times--pop up a
+dialog box inquiring names and descriptions of shapes that have not yet been
+given explicit names or descriptions.</p>
+
+
+<h4>3.3. Special objects</h4>
+
+<p>There are a number of objects that can appear on a draw page, that
+deserve special consideration:</p>
+
+<ul>
+
+<li><b>Animations</b> are normal shapes that can change their positions or
+appearances.  They will be represented like static shapes.  Their state at
+the end of the animation will be exposed.  It has yet to be discussed
+whether to provide a flag that a shape is animated and additional
+information that describes the animation.</li>
+
+
+<li><b>Special effects for changing slides</b> pose the problem that for a
+short time two slides can be seen at the same place and that the visibility
+changes for all their shapes.  The first approach to solve this problem will
+be to not represent effects for slide changes at all.  At the end of the
+effect the AT will be informed of a change of the complete window.</li>
+
+<li><b>Connectors</b> connect exactly two shapes.  They are represented by entries in
+the <code>XAccessibleRelationSet</code> object returned by the object from
+which the connection originates.
+</li>
+
+</ul>
+ 
+
+<h3>4. Impress Outline View</h3>
+
+<p>The Impress outline view is a relatively simple document visualization and
+its UAA representation is straightforward.  It consists of a hierarchical
+view of most of the textual information on all slides.  Each slide has a
+top-level entry.  The text on the slides follows properly indented.</p>
+
+<p>The UAA tree will use objects implementing
+<code>AccessibleEditableText</code> which are nested according to the
+hierarchy of the text in the outline view.  It will be only those objects be
+available that lie inside the visible area.</p>
+
+<p>Entering the outline view creates a preview window that shows a preview
+of the slide who's text in the outline view contains the cursor.  Its
+content is a single draw page and can be represented accordingly.  Because
+the preview is not directly editable, there is no need to make the preview
+window focusable.</p>
+
+<br></body>
+</html>
+

Propchange: incubator/ooo/ooo-site/trunk/content/ui/accessibility/proposal-impress.html
------------------------------------------------------------------------------
    svn:eol-style = native



Mime
View raw message