office-accessibility message

Subject: Re: [office-accessibility] ODF Accessibility Requirements draft(s) -reply with changes by 5pm PST Friday 26May

From: Peter Korn <Peter.Korn@Sun.COM>
To: office-accessibility@lists.oasis-open.org
Date: Fri, 26 May 2006 13:03:38 -0700

Greetings all,

Attached please find in ODF and HTML format the May 26th version.  It 
contains all of Dave's suggestions and his new graphic, with the 
exception of the "in class" change which Janina felt we should keep.


Regards,

Peter
> Dave Pawson writes:
>   
>> On 26/05/06, Peter Korn <Peter.Korn@sun.com> wrote:
>> Section 1.0
>> para 1. Says ... where instructors tell students in class to turn to a
>> specific page.
>> Is 'in class' redundant/
>>     
>
> Perhaps, but I'd prefer to keep it in order to be clear we're talking
> about a group of people all getting on the same page. In other words, we
> don't want anyone to get confused because they start thinking of a one
> on one tutoring model of instruction.
> Janina
>

odf11requirements052606.odt

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 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 in class 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 [HTML4]'s <THEAD> and <TBODY> elements for rows.

</oneOrMore>

</element>

</define>

</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 [HTML4]'s <THEAD> and <TBODY> elements.

</oneOrMore>

</element>

</define>

</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:

figure 1

The following are the suggested schema modifications:

9.1.4

...

The draw:id attribute assigns a unique ID to a drawing page.

</attribute>

</optional>

</attribute>

</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 [xmlschema-2] (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>

</define>

</define>

</define>

</define>

</define>

</define>

</define>

</define>

</define>

</define>

</define>

</define>

</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: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: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 who are members of the group should visible only when the group is expanded.

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:

</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.

</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:

<ref name="table-table"/>

</choice>

</zeroOrMore>

</optional>

</zeroOrMore>

</optional>

</optional>

</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>