OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [office-accessibility] Accessibility Evaluation of theOpenDocument v1.0 specification


Hi Janina,
> A quick question about this document ...
>
> Is it private to Oasis members? Or can it be shared?
>   
All e-mail sent to <office@lists.oasis-open.org> is public, archived at 
http://www.oasis-open.org/archives/office/  The particular message you 
are asking about can be found at: 
http://www.oasis-open.org/archives/office/200605/msg00107.html

Note also, my blog entry of 26May06 talks about our work, and links to 
the message (above), and also the three attachments directly.  See 
http://blogs.sun.com/roller/page/korn/20060526


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

> Thanks.
>
> Janina
>
> Peter Korn writes:
>   
>> Greetings,
>>
>> As set forth in the Statement of purpose of the Accessibility 
>> Subcommittee of the OASIS ODF Technical Committee, the Accessibility 
>> Subcommittee submits their report of the outcome of their accessibility 
>> evaluation of the OpenDocument v1.0 specification.  Our report is 
>> attached, in ODF, PDF, and XHTML formats.
>>
>> Here is our Executive Summary:
>>
>>  The ODF Accessibility Subcommittee has identified 9
>>  accessibility issues in ODF 1.0, and proposes candidate
>>  solutions to them. With these changes, we believe that ODF
>>  will meet or exceed the accessibility support provided in
>>  all other office file formats as well as that specified in
>>  the W3C Web Content Accessibility Guidelines 1.0.
>>
>>  Furthermore, these modifications will enable ODF to support
>>  the authoring of DAISY digital talking books, a worldwide
>>  standard used by blind, low vision, learning disabled, and
>>  other print impaired communities.
>>
>>  The recommended changes address:
>>
>>    * Alternative text for non-text objects (3 recommendations)
>>    * Proper association of captions to captioned content
>>    * Encoding of pagination information
>>    * Preservation of table semantic structure imported from
>>      other file formats
>>    * Proper encoding of authored table header content
>>    * Author-defined logical navigation of page objects in
>>      presentations
>>    * Provision of alternative text hints for hyperlinks
>>
>>  Furthermore, we request that the appropriate text be added to
>>  the ODF specification to indicate how this accessibility meta
>>  data is mapped by the authoring tool to a platform accessibility
>>  API as well as their accessibility applicability in the
>>  specification.
>>
>>  To fully address the needs of people with disabilities in using
>>  ODF, an ODF application must meet a number of accessibility
>>  requirements as well.  ODF application developers should be
>>  provided with implementation guidelines to meet these
>>  requirements.
>>
>>
>> It is the intention of this subcommittee to continue working, now with 
>> our focus on the new goal of defining and delivering improvements to the 
>> efficiency and usability of ODF by people with disabilities that goes 
>> beyond the current state of the art.  These improvements include: 
>> effective blind access to slide presentations; partnering with the W3C 
>> to tackle SVG graphics accessibility; better access to graphs and 
>> charts; and improved navigation models for tabular data.  We look 
>> forward to delivering to the technical committee our thoughts and 
>> recommendations in these areas for consideration in future versions of 
>> the ODF specification.
>>
>>
>>
>> On behalf of the OASIS ODF Accessibility Subcommittee,
>>
>>
>> Peter Korn
>> Accessibility Architect,
>> Sun Microsystems, Inc.
>>
>>     
>
>
>
>   
>>    May 26, 2006
>>
>> ODF Access Requirements
>>
>> OASIS ODF Accessibility Subcommittee
>>
>> Executive Summary
>>
>>
>>
>> The ODF Accessibility Subcommittee has identified 9 accessibility issues in ODF
>> 1.0, and proposes candidate solutions to them.  With these changes, we believe
>> that ODF will meet or exceed the accessibility support provided in all other
>> office file formats as well as that specified in the W3C Web Content
>> Accessibility Guidelines 1.0.
>>
>>
>>
>> Furthermore, these modifications will enable ODF to support the authoring of
>> DAISY digital talking books, a worldwide standard used by blind, low vision,
>> learning disabled, and other print impaired communities.
>>
>>
>>
>> The recommended changes address:
>>
>>      * Alternative text for non-text objects (3 recommendations)
>>      * Proper association of captions to captioned content
>>      * Encoding of pagination information
>>      * Preservation of table semantic structure imported from other file
>>        formats
>>      * Proper encoding of authored table header content
>>      * Author-defined logical navigation of page objects in presentations
>>      * Provision of alternative text hints for hyperlinks
>>
>>
>>
>> Furthermore, we request that the appropriate text be added to the ODF
>> specification to indicate how this accessibility meta data is mapped by the
>> authoring tool to a platform accessibility API as well as their accessibility
>> applicability in the specification.
>>
>>
>>
>> To fully address the needs of people with disabilities in using ODF, an ODF
>> application must meet a number of accessibility requirements as well.  ODF
>> application developers should be provided with implementation guidelines to
>> meet these requirements.
>>
>>
>>
>> 1.0 Requirement: Provide for soft page breaks in the specification
>>
>>
>>
>> Users are unable to share common page numbering when rendered with different
>> applications, on different systems. This negatively impacts conversions to
>> [1]DAISY digital talking books which utilize page-based navigation as a common
>> reference model to printed material, as well as Braille and large print uses. A
>> common use of these alternate formats is in classrooms, where instructors tell
>> students to turn to a specific page in a book.
>>
>>
>>
>> When a document is paginated the soft page break elements should be exported.
>> We  suggest this be implemented by introducing a new XML tag in writer similar
>> to hard page breaks for soft page breaks.
>>
>>
>>
>> 2.0 Requirement: Correct wording in specification to require table header
>> structural markup
>>
>>
>>
>> Users are unable to recognize all of the table headers that are created as
>> table headers in ODF 1.0.
>>
>>
>>
>> These two sections require changes in the ODF 1.0 specification as defects were
>> discovered during assistive technology interoperability testing with tables.
>> This will impact office applications today as they have been found to
>> incorrectly use styling vs. declarative markup for indicating table headers.
>> Declarative markup is essential for determining proper table structure
>> semantics. Styling does not indicate semantic intent.
>>
>>
>>
>>   8.2.2 Header Columns
>>
>>   For accessibility purposes, header information is needed. Therefore, any
>>   columns designated as headers by the author must be tagged as such by
>>   encapsulating them within the <table:table-header-columns>. Using style is
>>   insufficient. If a table does not fit on a single page, a set of adjacent
>>   table columns can be automatically repeated on every page. To do so, their
>>   columns descriptions have to be included in a <table:table-header-columns>
>>   element. Descriptions of columns that shall not be repeated on every page can
>>   be included into a <table:table-columns> element, but don't have to. A table
>>   must not contain more than one <table:table-header-columns> element, and a
>>   <table:table-columns> must not follow another <table:table-columns> element.
>>   Twith the only exception areof tables that contain grouped columns (see
>>   8.2.3). Such tables contain more than one <table:table-header-columns>
>>   element, provided that they are contained in different column groups and the
>>   columns contained in the elements are adjacent.
>>
>>   Applications that do not support header columns have to process header column
>>   descriptions the same way as non header column descriptions.
>>
>>   The <table:table-header-columns> and <table:table-columns> element are very
>>   similar to 's <THEAD> and <TBODY> elements for rows.
>>
>>   <define name="table-table-header-columns">
>>
>>           <element name="table:table-header-columns">
>>
>>                   <oneOrMore>
>>
>>                           <ref name="table-table-column"/>
>>
>>                   </oneOrMore>
>>
>>           </element>
>>
>>   </define>
>>
>>
>>   <define name="table-table-columns">
>>
>>           <element name="table:table-columns">
>>
>>                   <oneOrMore>
>>
>>                           <ref name="table-table-column"/>
>>
>>                   </oneOrMore>
>>
>>           </element>
>>
>>   </define>
>>   8.2.4 Header Rows
>>
>>   For accessibility purposes, header information is needed. Therefore, any rows
>>   designated as headers by the author must be tagged as such by encapsulating
>>   them within the <table:table-header-rows>. Using style is insufficient. If a
>>   table does not fit on a single page, a set of adjacent table rows can be
>>   automatically repeated on every page. To do so, their row elements have to be
>>   included in a <table:table-header-rows> element. Rows that shall not be
>>   repeated on every page can be included into a <table:table-rows> element, but
>>   don't have to. A table must not contain more than one
>>   <table:table-header-rows> element, and a <table:table-rows> must not follow
>>   another <table:table-rows> element. The onlyone exception to this isare a
>>   tables that contains grouped rows (see 8.2.5). Such a tables contains more
>>   than one <table:table-header-rows> element, provided that they are contained
>>   in different row groups and the rows contained in the elements are adjacent.
>>
>>   Applications that do not support header rows have to process header rows the
>>   same way as non header rows.
>>
>>   The <table:table-header-rows> and <table:table-rows> element are very similar
>>   to 's <THEAD> and <TBODY> elements.
>>
>>   <define name="table-table-header-rows">
>>
>>           <element name="table:table-header-rows">
>>
>>                   <oneOrMore>
>>
>>                           <ref name="table-table-row"/>
>>
>>                   </oneOrMore>
>>
>>           </element>
>>
>>   </define>
>>
>>
>>   <define name="table-table-rows">
>>
>>           <element name="table:table-rows">
>>
>>                   <oneOrMore>
>>
>>                           <ref name="table-table-row"/>
>>
>>                   </oneOrMore>
>>
>>           </element>
>>
>>   </define>
>>
>> 3.0 Requirement: Provide for author-specified, logical navigation in
>> presentations
>>
>>
>>
>> Authors are unable to indicate a logical navigation order for traversing
>> through objects in ODF presentations as distinct from z-order. The inability to
>> specify a logical navigation order makes it difficult for some users to
>> properly understand a drawing or presentation. For example, if a presentation
>> was designed such that groups of objects represented a logical process to be
>> followed, a blind user would not be able to follow the correct sequence unless
>> specified.
>>
>>
>>
>> We need a mechanism to allow the author to specify a logical, intent-based,
>> navigation order independent of the default document navigation order. We
>> suggest that a nav-order attribute be provided in <draw:page> so that the
>> author may specify the navigation order of the presentation slide or drawing.
>> This optional attribute should only be specified once the author chooses to
>> provide a navigation order. The suggested schema changes for the nav-order
>> attribute addition to <draw:page> are defined below. The nav-order targets
>> encompass all drawing elements and embedded objects unless they are embedded in
>> a <draw:g>. All drawing elements and embedded objects must be assigned an XML
>> id and they must appear in the nav-order list. Once a navigation order has been
>> specified by the author, all new drawing objects shall be assigned an XML id
>> and placed in the nav-order list. Our UI suggestion is that user agents, which
>> employ a navigation tool, allow the author to selectively choose one or more
>> objects and alter their position in the navigation order as shown here:
>>
>>
>>
>>    Navigator window - changing slide object navigation order figure 1
>>
>>
>>
>>   The following are the suggested schema modifications:
>>   9.1.4
>>
>>   ...
>>
>>
>>   The draw:id attribute assigns a unique ID to a drawing page.
>>
>>   <define name="draw-page-attlist" combine="interleave">
>>
>>           <optional>
>>
>>                   <attribute name="draw:id">
>>
>>                           <ref name="ID"/>
>>
>>                   </attribute>
>>
>>           </optional>
>>
>>       <optional>
>>
>>           <attribute name="draw:nav-order">
>>
>>               <ref name="IDREFS">
>>
>>           </attribute>
>>
>>       <optional>
>>
>>   </define>
>>
>>
>>   The draw:nav-order attribute defines a logical navigation sequence based on a
>>   collection of unique IDREFs.  If this optional attribute is present, it must
>>   include all graphic elements not contained within a <draw:g> tag.  This
>>   attribute should reflect the intentional ordering of graphics as set by the
>>   document author.
>>
>> 16.1 Data Types
>>
>> The following data types are used within this specification:
>>
>>      * W3C Schema data types as defined in (referenced by <ref> elements named
>>        the same as the corresponding data types)
>>           + string
>>           + date
>>           + time
>>           + dateTime
>>           + duration
>>           + integer
>>           + nonNegativeInteger
>>           + positiveInteger
>>           + double
>>           + anyURI
>>           + base64Binary
>>           + ID
>>           + IDREF
>>           + IDREFS
>>
>>   Relax-NG definitions for the W3C schema data types:
>>
>>   <define name="string">
>>
>>           <data type="string"/>
>>
>>   </define>
>>
>>   <define name="date">
>>
>>           <data type="date"/>
>>
>>   </define>
>>
>>   <define name="time">
>>
>>           <data type="time"/>
>>
>>   </define>
>>
>>   <define name="dateTime">
>>
>>           <data type="dateTime"/>
>>
>>   </define>
>>
>>   <define name="duration">
>>
>>           <data type="duration"/>
>>
>>   </define>
>>
>>   <define name="integer">
>>
>>           <data type="integer"/>
>>
>>   </define>
>>
>>   <define name="nonNegativeInteger">
>>
>>           <data type="nonNegativeInteger"/>
>>
>>   </define>
>>
>>   <define name="positiveInteger">
>>
>>           <data type="positiveInteger"/>
>>
>>   </define>
>>
>>   <define name="double">
>>
>>           <data type="double"/>
>>
>>   </define>
>>
>>   <define name="anyURI">
>>
>>           <data type="anyURI"/>
>>
>>   </define>
>>
>>   <define name="base64Binary">
>>
>>           <data type="base64Binary"/>
>>
>>   </define>
>>
>>   <define name="ID">
>>
>>           <data type="ID"/>
>>
>>   </define>
>>
>>   <define name="IDREF">
>>
>>           <data type="IDREF"/>
>>
>>   </define>
>>
>>   <define name="IDREFS">
>>
>>           <data type="IDREFS"/>
>>
>>   </define>
>>
>>
>> 4.0 Requirement: Alternative text for non-text image- map elements
>>
>>
>>
>> Image maps do not provide for alternative text that is essential for
>> accessibility.
>>
>>
>>
>> We recommend that an <svg:title> element be provided as an optional element to
>> the following:
>>
>>
>>
>> draw:area-rectangle
>>
>> draw:area-circle
>>
>> draw:area-polygon
>>
>>
>>
>> Text should be added to these elements as follows:
>>
>>
>>
>> <svg:title> is used as a short accessible name. When transcoding from another
>> document format to ODF the short names, like HTML's alt text on the <img> tags
>> shall shall be mapped to the <svg:title> element. Alternative text in Microsoft
>> Office is considered a short name and should be mapped accordingly.
>>
>>
>>
>> <svg:desc> is used for the long description in support of accessibility.
>>
>>
>>
>> 5.0 Requirement: Alternative text for Drawing layer
>>
>>
>>
>> Drawing layers do not provide for alternative text that is essential for
>> accessibility.
>>
>>
>>
>> We recommend that <svg:title> element be provided as optional element to
>> <draw:layer>. This element must apply to all ODF document formats for which
>> <draw:layer> is used.
>>
>>
>>
>> Text should be added as follows:
>>
>>
>>
>> <svg:title> is used as a short accessible name. When transcoding from another
>> document format to ODF the short names, like HTML's alt text on the <img> tags
>> shall shall be mapped to the <svg:title> element. Alternative text in Microsoft
>> Office is considered a short name and should be mapped accordingly.
>>
>>
>>
>> <svg:desc> is used for the long description in support of accessibility.
>>
>>
>>
>> 6.0 Requirement: Alternative text for drawing objects (line 5926 of spec.)
>>
>>
>>
>> Drawing objects do not provide for alternative text that is essential for
>> accessibility.
>>
>>
>>
>> The <svg:title> and <svg:desc> elements must be provided as optional elements
>> to all drawing shape elements defined below for all ODF document formats for
>> which these drawing shapes are used.
>>
>>
>>
>> The following are the drawing shape elements:
>>
>>
>>
>> <draw:rect>
>>
>> <draw:line>
>>
>> <draw:polyline>
>>
>> <draw:polygon>
>>
>> <draw:regular-polygon>
>>
>> <draw:path>
>>
>> <draw:circle>
>>
>> <draw:ellipse>
>>
>> <draw:g>
>>
>> <draw:page-thumbnail>
>>
>> <draw:frame>
>>
>> <draw:measure>
>>
>> <draw:caption>
>>
>> <draw:connector>
>>
>> <draw:control>
>>
>> <dr3d:scene>
>>
>> <draw-custom-shape>
>>
>>
>>
>> Text should be added to these elements as follows:
>>
>>
>>
>> <svg:title> is used as a short accessible name. When transcoding from another
>> document format to ODF the short names, like HTML's alt text on the <img> tags
>> shall shall be mapped to the <svg:title> element. Alternative text in Microsoft
>> Office is considered a short name and should be mapped accordingly.
>>
>>
>>
>> <svg:desc> is used for the long description in support of accessibility.
>>
>>
>>
>> User agents supporting platform accessibility APIs should follow the following
>> conventions for supporting the accessible name, accessible description
>> (accessible help on Windows systems), and describedBy relationships:
>>
>>
>>
>> If an <svg:title> element is provided it should map to the accessible name. If
>> not, the name should use the text referenced the text element identified by the
>> draw:describedby attribute. <svg:desc> must be used to support the accessible
>> description. User agents shall not manufacture names for the <svg:title>
>> element, such as using the drawing object followed by a cardinal number in a
>> string as it is used for accessibility. Name assignments such as these provide
>> no semantic meaning to the user.
>>
>>
>>
>> Guidance for authors:
>>
>> Authors should not assign names to objects having no semantic value. If no name
>> is assigned the caption text will be used in its place. <svg:title> shall take
>> precedence over the caption text for accessible name assignment by the user
>> agent.
>>
>>
>>
>> Assignment of the long description should only be necessary when a drawing
>> object is significantly complex and the user needs more information to describe
>> it. Long descriptions would be more applicable to drawing groupings than basic
>> drawing shapes.
>>
>>
>>
>> Authoring tool responsibility for presenting and prompting for the <svg:title>
>> and <svg:desc>:
>>
>>
>>
>> Authoring tools should provide an option from an objects context menu to allow
>> the user to enter the text for either of these elements as a minimum. More
>> proactive authoring tools should have a facility for prompting the author for
>> this text. Since <svg:desc> is a long description, a text area vs. a text field
>> should be used to prompt the user accordingly in GUI-based authoring tools like
>> Workplace and Open Office.
>>
>>
>>
>> Navigation tools, such as in Workplace and Open Office, used to list the
>> objects in the view should provide
>>
>> the type of object followed by the contents of <svg:title>. The title must have
>> been entered by the author.
>>
>>
>>
>> For <draw:g> elements the drawing objects which are members of the group should
>> visible only when the group is expanded.
>>
>>
>>
>>    Navigator window - changing graphics navigation order figure 2
>>
>>
>>
>> 7.0 Requirement: Establish clear relationships between objects and their
>> captions
>>
>>
>>
>> Captions are not clearly associated with the drawing objects which they caption
>> and this is needed for accessibility.
>>
>> Establish clear relationship between a drawing objects and its caption by
>> including a new optional draw:describedby attribute to the following drawing
>> objects.
>>
>>
>>
>> <draw:rect>
>>
>> <draw:line>
>>
>> <draw:polyline>
>>
>> <draw:polygon>
>>
>> <draw:regular-polygon>
>>
>> <draw:path>
>>
>> <draw:circle>
>>
>> <draw:ellipse>
>>
>> <draw:g>
>>
>> <draw:page-thumbnail>
>>
>> <draw:measure>
>>
>> <draw:caption>
>>
>> <draw:connector>
>>
>> <draw:control>
>>
>> <dr3d:scene>
>>
>> <draw-custom-shape>
>>
>> <dr3d:scene>
>>
>> <draw:frame>
>>
>>
>>
>> draw:describedby shall take a value of IDREF. The value for draw:describedby
>> attribute shall be the target id assigned to the <text:p> used to represent the
>> corresponding caption. As text:p is an XML element it may have an ID assigned
>> by default. The following attribute list should be included as optional to the
>> above drawing objects:
>>
>>
>>
>> <define name="common-draw-describedby-attlist" combine="interleave">
>>
>> <attribute name="draw:desribedby">
>>
>> <ref name="IDREF"/>
>>
>> </attribute>
>>
>>  </define>
>>
>>
>>
>> When a caption is assigned by a user agent, an id must be assigned to the
>> element containing the text used to caption a drawing element. The drawing
>> element being captioned must then be assigned the draw:describedby attribute
>> with an IDREF equivalent to the id of the captioning text thus establishing a
>> relationship between the captioned text and the object captioned as needed for
>> accessibility. Removing the caption should result in removing the
>> draw:describedby attribute of the object that was being captioned.
>>
>>
>>
>> If the user agent supports a platform which provides a draw:describedby
>> relationship in its accessibility API, this relationship for captions should be
>> used to fulfill the relationship.
>>
>> 8.0 Requirement: Establish text hints for hypertext links
>>
>>
>>
>> Hypertext links do not provide hints as to the destination of a link. This is
>> required for accessibility so that users may make informed decisions. This also
>> a W3C Web Content Accessibility Guideline requirement.
>>
>>
>>
>> We recommend that the <svg:title> element must be provided as an optional
>> element to <text:a>.
>>
>>
>>
>> <svg:title> is used as a short accessible description for hint text. When
>> transcoding from another document format to ODF the alt text, shall be mapped
>> to the <svg:title> element. When exporting ODF documents to HTML, the contents
>> of title text should be mapped to title attribute text on HTML anchor tags. As
>> a minimum, authoring tools should provide a mechanism to provide the hint text.
>>
>>
>>
>> The title text should be made accessible to the assistive technology and user.
>> The user agent should allow for programmatic access through standard
>> accessibility APIs such as the accessible description. Users should experience
>> visible access to the hint text via the keyboard or mouse.
>>
>> 9.0 Requirement: Provide for structured tables in presentations
>>
>>
>>
>> Users importing non-ODF slides that contain tables need access to the table
>> structure via their assistive technology.  Native table support with access to
>> full semantic structure will be addressed in a future release of the ODF
>> specification.  Meanwhile, tables imported into ODF from another file format
>> must have their structure preserved.
>>
>>
>>
>> We suggest that ODF applications be modified immediately to import tables in
>> presentation as embedded spreadsheets.  We further suggest that in the future
>> tables be made a first class object within presentations, similar to they way
>> the are implemented in Writer. Please see the Florian Reuter draft proposal in
>> appendix 1.0 which addresses the accessibility requirements we have identified.
>>
>>
>>
>> Miscellaneous Corrections to ODF 1.0 Specification
>>
>>   Section 9.2.15 Fix incorrect documentation in z-index
>>
>>
>>   We believe the following may be an oversight when specifying z-index.
>>
>>     Z-Index
>>
>>     Drawing shapes are rendered in a specific order. In general, the shapes are
>>     rendered in the order in which they appear in the XML document. To change
>>     the order, use the svg:width and svg:heightdraw:z-index attribute.
>>
>>     This attribute is optional.
>>
>>     <define name="common-draw-z-index-attlist">
>>
>>             <optional>
>>
>>                     <attribute name="draw:z-index">
>>
>>                             <ref name="nonNegativeInteger"/>
>>
>>                     </attribute>
>>
>>             </optional>
>>
>>     </define>
>>
>> Appendix
>>
>>
>>
>>   1.0 Florian Reuter draft proposal for future table support
>>
>>     Problem:
>>
>>     Currently tables are not supported within presentations. According to the
>>     OpenDocument specification tables can only be inserted to presentations by
>>     surrounding them with a text box.
>>
>>     What is needed is a table support in OpenDocument, such that tables can be
>>     put to presentations directly. One important issue here is to preserve
>>     accessibility, i.e. is it possible to navigate through tables with e.g. a
>>     screen reader.
>>     Proposed Enhancement
>>
>>     We propose the following enhancements to the OpenDocument specification and
>>     the OpenDocument schema:
>>
>> 9.3 Frames
>>
>> Modify the specification of frames, such that tables can also appear in
>> frames:
>>
>> <define name="draw-frame">
>>
>>     <element name="draw:frame">
>>
>>         <ref name="common-draw-shape-with-text-and-styles-attlist"/>
>>
>>         <ref name="common-draw-position-attlist"/>
>>
>>         <ref name="common-draw-rel-size-attlist"/>
>>
>>         <ref name="presentation-shape-attlist"/>
>>
>>         <ref name="draw-frame-attlist"/>
>>
>>         <zeroOrMore>
>>
>>             <choice>
>>
>>                 <ref name="draw-text-box"/>
>>
>>                 <ref name="draw-image"/>
>>
>>                 <ref name="draw-object"/>
>>
>>                 <ref name="draw-object-ole"/>
>>
>>                 <ref name="draw-applet"/>
>>
>>                 <ref name="draw-floating-frame"/>
>>
>>                 <ref name="draw-plugin"/>
>>
>>                 <ref name="table-table"/>
>>
>>             </choice>
>>
>>         </zeroOrMore>
>>
>>         <optional>
>>
>>             <ref name="office-event-listeners"/>
>>
>>         </optional>
>>
>>         <zeroOrMore>
>>
>>             <ref name="draw-glue-point"/>
>>
>>         </zeroOrMore>
>>
>>         <optional>
>>
>>             <ref name="draw-image-map"/>
>>
>>         </optional>
>>
>>         <optional>
>>
>>             <ref name="svg-desc"/>
>>
>>         </optional>
>>
>>         <optional>
>>
>>             <choice>
>>
>>                 <ref name="draw-contour-polygon"/>
>>
>>                 <ref name="draw-contour-path"/>
>>
>>             </choice>
>>
>>         </optional>
>>
>>     </element>
>>
>> </define>
>>
>>     Interoperability discussion
>>
>>     Presentation applications allow graphic-properties on table cells. This
>>     means, that styles referenced by tables cells may contain
>>     graphic-properties.
>>     Example
>>
>>     Consider for example the following table:
>>
>>     The above table would be encoded in an OpenDocument spreadsheet as
>>     follows:
>>
>>     <office:body>
>>
>>      <office:presentation>
>>
>>       <draw:page>
>>
>>        <draw:frame svg:x="5cm" svg:y="7cm">
>>
>>        <table:table table:name="SampleTable" table:style-name="Table1">
>>
>>         <table:table-column table:style-name="Table1.Column"
>>     table:number-columns-repeated="3"/>
>>
>>         <table:table-header-rows>
>>
>>          <table:table-row>
>>
>>           <table:table-cell table:style-name="Table1.H"
>>     office:value-type="string">
>>
>>            <text:p>Header1</text:p>
>>
>>           </table:table-cell>
>>
>>           <table:table-cell table:style-name="Table1.H"
>>     office:value-type="string">
>>
>>            <text:p>Header2</text:p>
>>
>>           </table:table-cell>
>>
>>           <table:table-cell table:style-name="Table1.H"
>>     office:value-type="string">
>>
>>            <text:p>Header2</text:p>
>>
>>           </table:table-cell>
>>
>>          </table:table-row>
>>
>>         </table:table-header-rows>
>>
>>         <table:table-row>
>>
>>          <table:table-cell table:style-name="Table1.B"
>>     office:value-type="string">
>>
>>           <text:p>A1</text:p>
>>
>>          </table:table-cell>
>>
>>          <table:table-cell table:style-name="Table1.B"
>>     office:value-type="string">
>>
>>           <text:p>A2</text:p>
>>
>>          </table:table-cell>
>>
>>          <table:table-cell table:style-name="Table1.B"
>>     office:value-type="string">
>>
>>           <text:p>A3</text:p>
>>
>>          </table:table-cell>
>>
>>         </table:table-row>
>>
>>         <table:table-row>
>>
>>          <table:table-cell table:style-name="Table1.B"
>>     office:value-type="string">
>>
>>           <text:p>B1</text:p>
>>
>>          </table:table-cell>
>>
>>          <table:table-cell table:style-name="Table1.B"
>>     office:value-type="string">
>>
>>           <text:p>B2</text:p>
>>
>>          </table:table-cell>
>>
>>          <table:table-cell table:style-name="Table1.B"
>>     office:value-type="string">
>>
>>           <text:p>B3</text:p>
>>
>>          </table:table-cell>
>>
>>         </table:table-row>
>>
>>         <table:table-row>
>>
>>          <table:table-cell table:style-name="Table1.B"
>>     office:value-type="string">
>>
>>           <text:p>C1</text:p>
>>
>>          </table:table-cell>
>>
>>          <table:table-cell table:style-name="Table1.B"
>>     office:value-type="string">
>>
>>           <text:p>C2</text:p>
>>
>>          </table:table-cell>
>>
>>          <table:table-cell table:style-name="Table1.B"
>>     office:value-type="string">
>>
>>           <text:p>C3</text:p>
>>
>>          </table:table-cell>
>>
>>         </table:table-row>
>>
>>        </table:table>
>>
>>        </draw:frame>
>>
>>       </draw:page>
>>
>>      </office:presentation>
>>
>>     </office:body>
>>
>>     with the following styles:
>>
>>     <style:style style:name="Table1" style:family="table">
>>
>>        <style:table-properties style:width="15cm" table:align="margins"/>
>>
>>     </style:style>
>>
>>     <style:style style:name="Table1.Column" style:family="table-column">
>>
>>        <style:table-column-properties style:column-width="5cm"/>
>>
>>     </style:style>
>>
>>     <style:style style:name="Table1.H" style:family="table-cell">
>>
>>        <style:table-cell-properties fo:padding="0.097cm"
>>     fo:border-left="0.002cm solid #000000" fo:border-right="none"
>>     fo:border-top="0.002cm solid #000000" fo:border-bottom="0.002cm solid
>>     #000000"/>
>>
>>        <style:graphic-properties draw:fill="gradient" draw:fill-color="#bbe0e3"
>>     draw:fill-gradient-name="Gradient_20_7"/>
>>
>>     </style:style>
>>
>>     <style:style style:name="Table1.B" style:family="table-cell">
>>
>>        <style:table-cell-properties fo:padding="0.097cm" fo:border="0.002cm
>>     solid #000000"/>
>>
>>     </style:style>
>>     Purpose of tables
>>
>>     In the current OpenDocument specification tables within presentations are
>>     represented based on shapes. This is not acceptable regarding accessibility
>>     issues. All OpenDocument processing entities SHOULD use the proposed table
>>     enhancement.
>>
>>     The new table feature of OpenDocument SHOULD also be reflected within
>>     OpenDocument processing entities such that the accessibility purpose of the
>>     proposed feature is preserved.
>>
>> References
>>
>>    1. http://www.daisy.org/
>>     
>
>
>   



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]