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 the OpenDocument v1.0 specification
A quick question about this document ...
Is it private to Oasis members? Or can it be shared?
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/
--
Janina Sajka Phone: +1.240.715.1272
Partner, Capital Accessibility LLC http://CapitalAccessibility.Com
Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada--Go to http://ScreenlessPhone.Com to learn more.
Chair, Accessibility Workgroup Free Standards Group (FSG)
janina@freestandards.org http://a11y.org
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]