[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]