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

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

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


Subject: RE: [office-accessibility] Accessibility Evaluation of the OpenDocument v1.0 specification


I think it would be helpful if the documents were uploaded directly into Kavi
rather than just the email attachment ... this will make them available to
anyone selecting "documents" from the TC Public Page.

Regards,

Mary 

> -----Original Message-----
> From: Michael.Brauer@Sun.COM [mailto:Michael.Brauer@Sun.COM] 
> Sent: Wednesday, May 31, 2006 2:42 AM
> To: Peter Korn
> Cc: Janina Sajka; OpenDocument Mailing List; 
> office-accessibility@lists.oasis-open.org
> Subject: Re: [office-accessibility] Accessibility Evaluation 
> of the OpenDocument 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]