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

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-accessibility 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


Peter, all,

I suggest that you also add a link to the document to the SC's web page. We 
should do the same with the TC web page as soon as the document has been 
approved by the TC, and therefore has become an official TC delivery.

Michael

Peter Korn wrote On 05/31/06 07:14,:
> 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/
>>>     
>>
>>
>>
>>   
> 
> 

-- 
Michael Brauer                                Phone:  +49 40 23646 500
Technical Architect Software Engineering      Fax:    +49 40 23646 550
StarOffice Development
Sun Microsystems GmbH
Sachsenfeld 4
D-20097 Hamburg, Germany                e-mail: michael.brauer@sun.com


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