OASIS Open Office Specification

This document is a guide for Office Applications, that support version 1.1 of the OpenDocument format, to promote and preserve accessible ODF documents. This guide is not a comprehensive guide for content mapping to platform accessibility APIs.

This document was last revised or approved by the Open Document Format for Office Applications (OpenDocument) Technical Committee on the above date. The level of approval is also listed above. Check the “Latest Version” or “Latest Approved Version” location noted above for possible later revisions of this document.

Technical Committee members should send comments on this specification to the Technical Committee's email list. Others should send comments to the Technical Committee by using the “Send A Comment” button on the Technical Committee's web page at http://www.oasis-open.org/committees/office/.

For information on whether any patents have been disclosed that may be eswsential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the Technical Committee web page at http://www.oasis-open.org/committees/office/ipr.php.

All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard, to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification.

OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this specification by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification. OASIS may include such claims on its website, but disclaims any obligation to do so.

OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.

The names "OASIS", “ODF” are trademarks of OASIS, the owner and developer of this specification, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see http://www.oasis-open.org/who/trademark.php for above guidance.

Background and Overview 7

Introduction 7

What is Accessibility? 7

Types/Categories of Access 7

Types of disabilities, and how they are addressed 8

Importance of the Accessibility of the ODF Application 12

Importance of Ensuring Authors Encode Accessibility Information into Documents 13

Putting the pieces together 13

ODF Application Accessibility 14

Keyboard Navigation Without Using a Mouse 14

Theme Support (including OS fonts & colors) 14

Interoperability with Assistive Technologies 15

Characteristics of Engineered Accessibility Frameworks 15

Supporting an Accessibility Framework 17

Dealing with the Absence of an Accessibility Frameworks 18

Special Issues for Web-based ODF Applications 18

ODF Help System Accessibility 18

Document Content Accessibility Basics 20

Document Navigation or Structure 20

Text document structure 20

Presentation document structure 21

Spreadsheet document structure 22

List structure 22

Page breaks 23

Table navigation 23

Provision of alternative text versions of document content. 23

Why do anything about it? 26

Summary, graphical and audio objects 26

Special considerations for subtables 26

Converting between ODF and other Document Formats 28

Preservation of Alternative Text 28

<svg:title> 28

HTML element using alt= “..” 28

<svg:desc> 30

Preservation of Document Structure Hierarchy and Landmarks 33

Preservation of Heading Structure 33

Preservation of list Structure 34

Preservation of Page Header and Footer structure 37

Preservation of Speaker Note elements 37

Preservation of Table structure 38

Preservation of Page Breaks 39

Maintaining the accessibility of Form Elements 39

Maintaining Association Captions 40

Preservation of MathML accessibility information 41

Preservation of Synchronized Media (animations) SMIL 42

Special Consideration for alternative media produced from ODF 43

Where and How Audio is Used for Accessibility 43

How ODF Fits In 43

Soft Page Breaks and Hard Page Numbering 44

Structural Markup 44

Glossary of Terms 45

Conformance 53

1Background and Overview

1.1Introduction

The Open Document Format v1.1 (ODF) is capable of encoding and persisting a tremendous amount of structural and semantic information needed by people with disabilities and the tools they use (assistive technologies) to gain access to computers and information. This document describes the things that an ODF 1.1 implementation must do in order to gain, persist, and present all of the information that ODF 1.1 is capable of persisting, so that users with disabilities are equally able to read, create, and edit documents – with full access to all of the meaning and intent – as their mainstream colleagues.

1.2What is Accessibility?

The Open Document Format v1.1 (ODF) is capable of encoding and storing a lot of structural and semantic information. This information is needed by people with disabilities and the tools they use (assistive technologies), to gain access to computers and information. This document provides guidelines for ODF 1.1 implementation. A successful ODF 1.1 implementation will enable users with disabilities to read, create, and edit documents – with full access to all of the meaning and intent – just like a person without any disability.

Accessibility is about enabling people with disabilities to participate in substantial life activities that include work and the use of services, products, and information. In the context of ODF documents, this means that people with disabilities should be able to participate fully in the creation, review, and editing process of the documents. A blind person, for example, should be able to work with a document someone else created (by getting a text description of the images used). A person should be able to fill out a form without using hands. A person with poor vision should be able to read through presentation materials easily.

1.2.1Types/Categories of Access

The first is direct access. With direct access, the person with the disability is capable of direct interaction . For example, a deaf person has direct access to a newspaper – the disability does not restrict the medium. A blind person (but not deaf) can use a phone easily.

The second category of access is mediated access, or access through an assistive technology. Here, the person with the disability is interacting with the media/medium via some other tool. A person with poor vision might use a magnifying glass to read a book (note that same person might have direct access to a large print book). Someone who is deaf might enjoy a television show via good captions.

The third category of access isn't really access. A friend reading the mail to the blind recipient might fall into this category. May be we can call this as indirect access.

Talking about computers, direct access is what that the program itself provides to the users. The large print theme of the desktop and applications is the equivalent of the large print book to a user with poor vision. For blind users, a special program called a screen reader is used which mediates the user's experience. It reads the text via speech (or renders it using a refreshable Braille display). A user for whom the large print theme doesn't work (but still has some vision), a screen magnifier, which magnifies the contents of the screen, is a viable good option.

It is worth noting that many of the things we have built specifically for accessibility for people with disabilities are used and appreciated by people without disabilities. Close captioning of television broadcasts has become very popular in noisy places like bars and airports; while captioning in multimedia presentations has allowed text searches of those presentations. Similarly, the wheelchair ramps that allow people in wheelchairs to easily move from the street to the sidewalk are much appreciated by delivery personnel, parents with strollers, and anyone else on wheels (bicycles, skateboards).

1.2.2Types of disabilities, and how they are addressed

There are several different types of disabilities, and they are addressed (or adapted to) with either direct or mediated access techniques. These types of disabilities mostly stem from impairments in one or more of the primary senses.

1.2.2.1Minor vision impairments

People with minor vision impairments have one or more problems that can be addressed via direct access techniques. These include some level of color blindness (roughly 10% of the male population worldwide has some level of color blindness), the inability to see text below 15 or 18 or 24 point text (an issue for most people as they age), or some reduction of their field of view that isn't very severe. To be considered a true impairment, the disability must be something that hasn't otherwise been fully addressed by corrective lenses such as glasses.

These users need the default presentation of the ODF application and ODF content rendered somewhat differently. For example, they might need a particular color scheme, or a special high-contrast scheme. They might need the size of the text and images to be larger. The specific techniques that ODF applications must employ for users with these needs are described in section 2.2.

1.2.2.2Major vision impairments

People with major vision impairments need more adaptation in the presentation of an ODF document than rendering the text in an alternate color scheme, or using a larger font. These users need the entire presentation magnified – typically between 2 and 16 times (one pixel becoming 4 to 256 pixels). Such a significant level of magnification cannot be accommodated within the boundaries of most computer screens. Instead, a second piece of software, an assistive technology called a screen magnifier, is used. It renders a magnified image to a virtual screen that is far larger than the physical screen. This screen magnifier software displays only the appropriate portion of the magnified screen on the physical screen: the portion that the user is interacting with at that moment of time. In addition, this screen magnifier may be magnifying an original, scaled image that is in a particular color scheme; or the magnifier itself may alter the colors. Some of the more sophisticated screen magnifiers offer additional features, such as

1.2.2.3Near or total blindness

There are people whose vision is so severe that they have effectively no usable vision at all. They use a different assistive technology to read and edit ODF documents – a screen reader. This software uses synthetic speech (or text-to-speech, commonly abbreviated to TTS) to read the contents of the screen, application, and document to the user. Such software tracks the object or text the user is interacting with (sometimes called the locus of focus) and reads that object or text to the user. This includes

Screen readers are sometimes combined with screen magnifiers, in which case magnification also tracks this locus of focus. Screen readers sometimes also support refreshable Braille displays in which case in addition to speech, the information is rendered to the Braille display. If the user is both deaf and blind, Braille will be the exclusive medium of information from the ODF document and application.

1.2.2.4Minor physical impairments

People with minor physical impairments have a variety of issues that prevent them from using the full keyboard or mouse easily. In order to support such users, all the functionality of the application should be operable in a non-time-dependent manner through a keyboard interface, except where the task requires analog, time-dependent input. This is also beneficial to users who don't have a physical impairment, but otherwise cannot use a mouse (such as a blind user, who cannot see the mouse pointer on the screen and so is functionally unable to effectively use the mouse).

1.2.2.5Major physical impairments without speech recognition

People with major physical impairments are typically unable to control their limbs. They can perhaps shrug a shoulder, or sip and puff on a straw, or move their head or at least their eyes. But they are unable to press a single key on a traditional keyboard.

When these impairments also affect their speech (or if they simply choose not to use speech recognition software), such users use on-screen keyboard software that is connected either to a switch device, which they can activate (a large button mounted to their wheelchair that they can press in some fashion, or a switch embedded within a straw, which they can 'press' by sipping or puffing on that straw), or by head movement that is tracked by a camera following a reflective dot on their forehead or glasses, or by eye movement that is tracked by a camera following their pupil.

The on-screen keyboard software has variety of techniques to translate these movements to the choices of individual keystrokes, or to entire words, which are then entered into the system as if they are entered from the keyboard. This is done by displaying a software keyboard on the screen, from which the user makes their choices.

Advanced on-screen keyboard software can actually provide remote access to accessible menus, toolbar elements, and other UI components on the software “keyboard” where the user can choose them..

Another, new type of assistive technology used by people with major physical impairments is the dynamic text entry application, which couples a predictive text system with head, eye, or switch movement to rapidly enter the most common sequences of text based on a probability model for a given language (or a given language domain such as medical terminology).

The users with major physical impairments are not able to move their body but their eyes are able to achieve more than 35 word-per-minute typing rates with such a software.

1.2.2.6Major physical impairments with speech recognition

This assistive technology not only translates the users' speech to text (for entry into the ODF document), but also allows the user to control the ODF application via speech.

For example, a user of this assistive technology might say the utterance “Menu File, Print” in order to choose the print item of the file menu. Or they might say “Select from 'Dear Mom' to 'please send money'” in order to select a range of text in the ODF document.

1.2.2.7Hearing impairments

People with hearing impairment have difficulty in hearing clearly, or perhaps cannot hear at all. A severe impairment may not be corrected by using a hearing aid.

The users with hearing impairment use an operating system feature called ShowSounds. They also use a different operating system feature called SoundSentry. ShowSounds is a system flag that indicates the application to captioned (For example; text captions displayed in an mpeg video) any speech and sounds made in a presentation. SoundSentry causes the operating system to generate a visual warning along with the audible warning tone.

1.2.2.8Cognitive impairments

People with cognitive impairments have one (or more) of a very wide range of disabilities. The cognitive impairments includes:

The users with cognitive impairments use one of a variety of assistive technologies, and/or application features, in order to use the computer more effectively. The assistive technologies and application features includes:

The users with cognitive impairments are capable of using the most popular assistive technology software into text-heavy applications like office suites, e-mail packages, and web browsers.

There are more severe cognitive impairments, which are not yet very well addressed - either by mainstream software, or by assistive technologies. Further research may improve the options available to these users.

1.3Importance of the Accessibility of the ODF Application

Ensuring that the ODF application is accessible to people is critical for the following reasons:

1.4Importance of Ensuring Authors Encode Accessibility Information into Documents

The ODF v1.1 specification includes many optional elements that are critical for document content accessibility.

It is vital that these optional elements should be used by document authors to produce an accessible document. It is therefore important that ODF applications, at the bare minimum, allow document authors to include these optional elements. But the user interface presented to the author for doing this should be straightforward, simple, easy to find, and easy to use.

The ideal ODF authoring/editing tool would have a feature or mode that audits ODF applications for its accessibility, and flags the accessibility problems it finds.

Just as all ODF applications help the author to create documents without spelling and grammatical errors, a good ODF application will likewise help the author to create documents, which are accessible to people with disabilities.

1.5Putting the pieces together

Software is composed of different components which, together form an accessible reading and editing experience for people with disabilities.

The tool, which the author used to created the ODF document, must offer a solution to encode the accessibility information needed by assistive technologies.

The ODF document reader must expose ODF accessibility information to any assistive technologies running on the operating system. This information should be provided through a rich accessibility framework. with the ideal situation of it being available with the operating system.

2ODF Application Accessibility

2.1Keyboard Navigation Without Using a Mouse

Every function of the accessible ODF application must be possible using the keyboard. Many users with physical impairments cannot use a mouse. For example; blind users cannot use a mouse because they cannot see where it is moving, will be unable to accomplish tasks using mouse.

However, it is not enough to support a sequence of keystrokes for accomplishing every task. The sequence of keystrokes should be efficient, and should follow conventions on that operating system for doing similar tasks (for example; F10 for focusing the menu bar; ESC for canceling dialog boxes; TAB for moving between controls in a dialog box). See these URLs for the common keystroke sequences for Windows, UNIX with GNOME, and Macintosh.

Another important thing about the keyboard accessibility support in the ODF application is compatibility with Operating System keyboard support features.

It is important to test the ODF application with all of these support features to avoid a compatibility problem..

Code which examines the state of modifier keys upon reception of an event, instead of the modifier flags in the event itself, is a likely source of StickyKey compatibility problems.

2.2Theme Support (including OS fonts & colors)

ODF applications must accept the color, contrast, and font choice information, which the user has made for his/her desktop.

Users with a range of vision impairments (such as red-green color blindness) make these settings so that they can see user interfaces running on their desktop. If the desktop setting of font size is larger than standard (for example, an 18 point font) the ODF application should ensure that no text in any menu, dialog box, or other user interface element is smaller than 18 point.

Ideally the ODF application should further optionally scale the document content, linked to the desktop font size setting, without requiring additional user interaction. This extends to every part of the ODF user interface, including things like print preview.

Desktops such as the GNOME desktop on a UNIX system offer an additional settings for vision impairments custom large print and high and low contrast icons. In these cases, the accessible ODF application should work according to these options.

Desktops such as the Macintosh desktop fail to offer desktop settings for color, contrast, and font size. Ideally, accessible ODF application used on such desktops will allow the user to choose colors and fonts which meet their needs, independent of the desktop.

2.3Interoperability with Assistive Technologies

One of the most important things for supporting accessibility that an ODF application must do is to be compatible with assistive technologies. For example, if the ODF application doesn't work with the screen reader application on a particular platform/operating system, then blind users won't be able to use that ODF application. If there is a basic level of interoperability between the ODF application and a screen reader, then blind users may be able to accomplish all of the reading and editing tasks, but not necessarily in a very efficient or productive manner.

The major operating systems are either shipping, or developing, an engineered accessibility framework specifically to facilitate the interoperability between assistive technologies and software applications.

The ODF application should support the accessibility framework, and fully implement its accessibility API, on the platform(s) it runs on. The API should fully expose the accessibility information provided in the ODF document such as IAccessible2.

2.3.1Characteristics of Engineered Accessibility Frameworks

An engineered accessibility framework that can provide the rich support for interoperability with assistive technologies, needed to yield a productive and efficient user interface for people with disabilities, has few common characteristics:

2.3.2Recommended Engineered Accessibility Frameworks

The following accessibility frameworks are recommended for ODF applications to use on their respective platforms:

2.3.3Supporting an Accessibility Framework

Whether the ODF application uses an existing user interface toolkit, which supports an accessibility framework, or implements all the framework support itself, it is important that the ODF application accurately exposes all of the information about all of the user interface elements that the accessibility framework can communicate. It is especially important that the ODF application fires events/signals whenever the user interface elements change the state, gain/lose focus, or their content changes.

This is critical because many assistive technologies are event driven – reacting to text appearing by speaking the text for the blind user, reacting to the caret moving within the text by reading the letters being moved through to the blind user, and moving the magnified view to track the caret for the low-vision user.

The ODF application development and testing team should test to ensure that the accessibility framework is properly implemented – both by using test tools, and also by using the ODF application through the assistive technologies available for that platform. This is ideally done by people with disabilities who are experienced with using assistive technologies However, even just turning off the monitor for a day and using the ODF application via a screen reader is extremely helpful.

2.3.4Dealing with the Absence of an Accessibility Frameworks

Today not every platform provides an accessibility framework that is sufficient to convey the richness of an ODF application, and which is supported by the assistive technologies on that platform. Unfortunately in these cases the only option may be to form a business relationship with one or more assistive technology vendors (who may then either support some non-OS-defined accessibility framework that the ODF application and assistive technology can agree on), or extend the reverse engineering techniques, which accessibility framework otherwise uses to provide access to that platform, or a combination of the two.

2.4Special Issues for Web-based ODF Applications

For web-based ODF applications, accessibility poses special challenges. The accessibility of the ODF application is significantly dependent upon the web client being used.

Web-based ODF applications should utilize the W3C WAI-ARIA specification (currently in draft form) for conveying all dynamic/interactive portions of their interface. Use of WAI-ARIA - through a browser that supports WAI-ARIA, such as Firefox, provides support for assistive technologies by conveying the content, meaning, context, and updates/changes of the user interface.

Further, the web-based ODF application must accept the CSS settings set by the users, in order to support color, contrast, and font settings, which the users indicate either on their desktop, in their web client, or via their own custom CSS.

The best choice of an accessible web client for dynamic web applications on a desktop computer (as of the day of release of this document) is Firefox on Windows. Firefox works to support exposure of WAI-ARIA accessibility API information via Firefox on UNIX and Macintosh systems is underway. The UNIX work is expected to finish in Firefox 3.0 by mid-2007.

2.5ODF Help System Accessibility

Help systems are often separate application from the ODF application. The Help system provides help about the ODF application, which from the end-user point of view, is a feature of the ODF application itself.

An ODF application is not fully accessible unless the associated help system is also accessible.

3Document Content Accessibility Basics

Access to content for people with disabilities has a number of aspects. These are discussed below.

3.1Document Navigation or Structure

Well written documents generally have a recognizable structure. An example structure is shown below

From this structure the reader can determine if the document is of interest and provides the navigation aid which may be used to quickly access specific content.

Access to the parts of a document that provide these clues is key to navigation.

A title is visible title text marked in XML as a text:h element. It is important that implementations support the user in generating appropriate XML. Visually bold centered text is not the same as a title as far as XML is concerned.

The appropriate use of styles greatly helps with accessibility. Use named styles in your document; these provide the foundation of the document structure which is used by access technology to convey meaning to the user.

3.1.1Text document structure

Named styles (heading 1, Default, List indent etc) are available to the user and provide structure in the saved XML file on disk. Additionally each of these named styles may be formatted for a given visual presentation. It is important to realize that the appropriate use of styles helps greatly, with accessibility providing the foundation of the document structure.

Authors should use named styles within a document since this provides the foundation for the document structure. With regard to visual presentation, this also allows a single style change to be reflected throughout the document. Style names can also be used when creating a table of contents. If two visually identical paragraphs are created, one using named styles and the other using styling attributes, it is important to realize that the XML produced will be different for each case.

The structure of an ODF text document, refers to the use of named styles. The automated processing of style information is used to generate a table of contents, cross references and more importantly, present the overall structure of the document for the reader.

When the document is saved into it's default form, an ODF document provides a structure based on the named styles which allows navigation and access for other tools, using the Extensible Markup Language (XML) semantic markup.

Other XML tools can be used to abstract a quick overview if needed, by selecting specific named styles which are key to the document structure.

Implementers need to assist the user in using named styles as opposed to modified font sizes and other presentational aspects.

There are three possible ways to obtain entries in a table of contents. These are, the headings (heading level 1 etc.), table of contents index marks, and named paragraph styles. The table of contents may be used as a document overview, so it is important from the point of view of accessibility as it helps readers navigate a document.

Advice: Use named styles in your document; these provide the foundation of the document structure which is used by access technology to convey meaning to the user.

3.1.2Presentation document structure

For a slide presentation similar logic may be used. The title of each slide presents a variation of a table of contents, providing the person using access technology with an overview of the presentation content. With meaningful titles a presentation outline is available even if the body of each slide is fully graphical. Beyond this, it is up to the author to help a user comprehend the presentation structure.

Within a single slide, ODF has the idea of a logical navigation order (see ODF 1.1, section 9.1.4). This enables the author to specify how the slide should be read. If the implementor helps the author to specify this navigation order then the end user can readily navigate between the objects on a slide as intended. For example, a keyboard user may use the TAB key to skip between the images on a slide, and access technology, which can present information about the image based on the textual alternative description.

Advice: Ensure a meaningful title for each slide. Ensure sufficient text on a single slide to extract essential information. Also ensure that there is a meaningful TAB navigation order for items within the slide.

3.1.3Spreadsheet document structure

There is little structure to inform the reader about the sheet, unless a spreadsheet has multiple sheets.

An informative heading given to each sheet can provide on overview of the contents of a spreadsheet. Implementors can help by making it easy to add such headers.

Row and column headings provide an anchor for the reader when navigating through the spreadsheet. If the data is accessed serially, as in the case where someone is accessing the spreadsheet via a text to speech system or a braille system, then it is easy to forget the heading of the column being accessed. The implementor can help by making it easy for the user to add row and column headings, and ensure that these are correctly marked up in the saved XML.

Advice: A reader normally looks for headings at the top of a spreadsheet. Column and row headings are essential for access technology.

3.1.4List structure

If not used properly lists can confuse the reader, especially if they are not well structured and presented. Nested lists are are often visually indented from the parent list item. This is not the correct way to produce well structured lists. Implementors should provide an appropriate nested structure for nested lists and help users create lists in an appropriate way.

Advice: Use named styles in your document; these provide the foundation of the document structure which is used by access technology to convey meaning to the user. This is particularly important in nested lists.

3.1.5Page breaks

When print users talk about printed matter, a common frame of reference is to use page 34, third paragraph from the bottom, or similar references. Unless a reader with sight problems can access the page numbers, this frame of reference is clearly an exclusion. Implementors should provide notification of page breaks on export.

The visual page breaks used in the print layout mode should be made available to access technology.

3.1.6Table navigation

It is necessary to indicate clearly which cells contain row and column headings. Implementers can help by prompting users to identify headers and marking them semantically within table:header-row. This allows access technology to inform the user what the column header is for the cell having current focus.

Users should ensure that those cells are structurally marked (using named styles) rather than visually marked (emphasis etc.). Implementers should ensure that table header content is available to access technology no matter what API is in use. The reason is to ensure that users have access to header information even when there are a number of pages which make up the table.

Advice: Use styles to name the row and column headings appropriately. Repeat headings if the table spans more than one page.

3.1.6.1Tables within presentations

ODF 1.1 does not support structural tables within presentations. Implementers can help by using embedded spreadsheet tables, which do have a structure. This is another case where visual and structural information can differ. Embedded spreadsheet tables have a fully navigable structure.

3.2Provision of alternative text versions of document content.

The implementor can also help by providing a function to add an alternative text representation in a consistent manner. If the user has to select different drop-down menus, with different fly-out options in each application, then interest is soon lost and the reader loses out. Choose a method which is common across applications and which helps the author add content easily. If the method works with line drawings, embedded images, audio clips etc., then the author gains confidence in the application and can help the reader gain access to the information provided by the author.

The image may be described in one of two ways. A simple decorative image can be described using the <svg:title> element. For a more complex image (or diagram etc.) there is the <svg:desc> element (equivalent to the HTML longdesc element) which provides a way of entering a more complete alternative to the visual object.

Next there is the draw:caption element. Implementors can help by encouraging the addition of captions (often a few words providing a label for the object which are visually associated with the object). Captions are associated with the description by means of the draw:caption-id attribute. This must be added to link the object and its description.

Implementors must provide the means to add these descriptions in a consistent manner across all office applications.

Advice: Encourage users to add textual descriptions for any images which are important to ensure the documents information is made available to all readers.

3.2.1Image maps

It is possible to assign areas of an image as being active with a hyper-link to another URI. This is commonly known as an imagemap. As with any image, a brief description should be provided using the <svg:title> element, or a longer description using <svg:desc> if a longer text alternative is needed.

These text descriptions should provide information about the content at the end of any links. Implementers can help the author to enter this by providing a standard dialog, letting the author enter text for the alternative descriptive text.

3.2.2Audio inserts

When a reader with a hearing impairment receives one of your documents will he or she hear what you have inserted? For example, if an audio object were attached to a paragraph, would you know about it? What do you know about it? What volume will it play at? How can a reader with a hearing impairment adjust the playback volume? If a reader has insufficient auditory sensitivity to access the clip, how can the implementor help the author to provide an alternative presentation? The most general method is to provide a textual alternative. How easy is it for an author to add that? Must the user learn a new technique? Help the reader by helping the author.

3.2.3Complex diagrams

If you enter a complex diagram like an organization chart as part of a report (See Figure 1), do you rely on readers having full access to it? What if one of them couldn't see it or couldn't make out the detail? Does this mean it's of no interest to them? No!

An implementer should ensure a consistent way in which the author can add a simple textual alternative. To the reader, the graphic is a variant form of an image, but to the author, the alternative text is another way of presenting the information. Implementors should help the user by making it easy to provide an alternative solutions.

For a complex graph the textual alternative could be equally complex. A good implementation will provide facilities which enable alternative text from a few words to a 100 word description. Does the input area flex with use? An implementor should try using it to describe a couple of graphics seen in text documents.

Advice: Ensure that readers who can't access your non-text content have an alternate textual description of the information you provide in a graphical or audio modality.

3.2.4Summary

Each of these (and there will be more) shows how we individually access information. Many of us scan information visually. Others don't, or can't. If an author provides equal access to all readers they can feel confident in reaching a maximum possible audience. If an author writes without consideration for the audience they may totally miss an important part of the information.

If an implementor makes it easy for an author to consider and meet the needs of the audience then the objective of transmitting information is achieved.

A subsequent section of the document may depend on a graphic to understand a later section. If a reader has totally missed that graphic (for whatever reason), then the document has less utility.

If you know all the recipients of your document then consider them all. If you are writing for a general audience then this document will provide guidance on how you can make it easier for them to access the information that you are passing on.

3.2.5Why do anything about it?

Consider receiving a document where one third of it is blacked out, or blank. Even if the summary makes sense, you are left wondering what you have missed. The cause for such a document may be censorship or a careless writer. If you are unable to access visual, auditory and textual content in a document then you are in the same situation when you receive a document prepared without consideration for accessibility.

3.2.6Summary, graphical and audio objects

For each change in media, think of potential readers who may not be able to access it. If the information is important, provide an alternative format for the reader.

3.3Special considerations for subtables

It is recommended that <table:is-subtable> should not be used. The ODF specification for <table:is-subtable> requires the use of a special cell addressing scheme. Cell addresses are an important structural aid for users who are blind and not able to visually determine the location of a cell within its table. Since the subtable addressing scheme is different from the normal one it is disorienting. The same visual effect can be obtained using <table:number-rows-spanned>

and

<table:number-columns-spanned>

The use of these attributes will result in cell addressing which is consistent with the surrounding table.

A1	B1	C1
A2	.B2.A1	.B2.B1
.B2.A2

In this example each cell contains the cell address as defined by the ODF specification. Examples of cell address are .B2.B1 and C1. Cell contents and cell addresses are provided to users of a ssistive t echnology (AT). Cell addresses provide essential location information to AT users.

In Table 1, above, there is a B2 (.B2.B1) under an C1. This location information will be confusing and disorienting for the user with visibility impairment. Without significant extra effort, a blind user has limited access to the subtable.

The cell location information is also important when using tables with row and column headers, for example the first row and first column in the table above. In this table the use of <table:is-subtable> results in a cell addressing scheme that is disjoint from the addressing scheme of the row and column headers and the semantic relationship is broken. For example, in the prior table cell C1 is a header of a B2 cell.

The visual equivalent of the prior table is the following table which will result when using <table:number-rows-spanned> and <table:number-columns-spanned>. In this case cell C1 is the header of cell C2 and a meaningful location relationship between the two cells is maintained.

A1	B1	C1
A2	B2	C2
B3

Table 2: Table using number-rows-spanned and number-columns-spanned attributes

4Converting between ODF and other Document Formats

Accessibility issues surrounding document format conversion are often overlooked. This section covers issues that an office application must conserve to preserve accessibility when converting between ODF documents and other Office documents such as HTML, DAISY, or MS Office.

4.1Preservation of Alternative Text

Alternative text is used to provide alternatives to non-text objects such as drawing or images. Throughout the ODF specification, <svg:title> and <svg:desc> are used to represent the short accessible name and long description of these document elements. Long descriptions are not new to HTML however they are new to office documents formats and consequently long descriptions may not need mapping.

Alternative text is used to describe a graphic or drawing object. The users with visibility impairment prefer to hear a short description for these document elements when navigating a document with the screen reader as it improves productivity as compared to using a long description.

The ODF Accessibility Subcommittee introduced long descriptions for drawing objects to provide more information about the drawings. This is particularly important for complex drawings formed from a group of smaller shapes.

When converting to and from ODF it is essential that alternative text is preserved.

4.1.1<svg:title>

The <svg:title> attribute represents the short accessible name of the non text drawing object.

Applications, supporting ODF, must ensure that the double quotes come through in the submitted document.

ODF 1.1 Element	MS Office	HTML element using alt= “..”	HTML element using title=“..”
<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>	¹Microsoft Office format mapping is incomplete due to limited alternative text support.	<IMG alt=””>	This is not used for the short name for images.
<text:a>	Hint text for links. The actual format is not available for listing here.	No alternative text attributed is provided.	<a title=””>
<draw:layer>	No mapping	N/A: No drawing layer in HTML.	N/A: No drawing layer in HTML.
<draw:image>		<IMG alt=””>	This is not used for the short name for images.
<draw:area-rectangle>	No mapping	<AREA Shape="rect" alt= “...”>	This is not used for the short name for images.
<draw:area-circle>	No mapping	<AREA Shape="circle" alt= “..”>	This is not used for the short name for images.
<draw:area-polygon>	No mapping	<AREA Shape="poly" alt= “..”>	This is not used for the short name for images.

Table 1 illustrates the proper mapping of ODF accessibility short names to HTML 4.01 and Microsoft Office .doc format.

Title	Tells the user about the contents in the documents.
Summary	Tells the user the important points covered in the document.
Table of content or similar navigation aid	Enables the user to find their way around the document.