MHonArc v2.5.0b2 -->
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]