Accessibility Issues with Office Open XML

Stephen A. Hockema
Jutta Treviranus
Adaptive Technology Resource Centre
University of Toronto

 

0. Preface / Update [added for Version 1.3]

In what follows, several accessibility issues with OOXML are identified.  As described below, the original source in the identification of some of these issues was a document published online by Microsoft at http://openxmldeveloper.org/archive/2007/07/02/Accessibility_of_Open_XML.aspx called “Accessibility of Ecma Office Open XML File Formats”.  After we published what follows, Microsoft updated their document, calling the revision "Version 1.01".  This is the version currently available at the above link (as of January 4, 2008).  In their revision, Microsoft claimed that many of the unsupported accessibility guidelines we discuss herein were, upon further analysis by them, actually supported by the OOXML standard after all.  However, upon investigating these new claims, we find that they are misleading:  in almost all of these cases, the checkpoint is not satisfied, despite Microsoft's amended claims.  Below, we have added explanations to our original analysis to point this out.  These additions will be in separate subsections under the appropriate subsections of Section 4.  Further, we have added an additional section, "6. Addendum", at the end of the document.  Needless to say, it remains our opinion that OOXML is an inaccessible document format and not suitable for international standardization nor widespread adoption.

 

1. Introduction 

Office Open XML (OOXML) is an electronic document file format based on XML originally developed by Microsoft Corporation for their proprietary Microsoft Office suite as an alternative to previous proprietary document formats. In December, 2006, the organization Ecma International published a standard (ECMA-376) based upon this format.² Ecma International then submitted this standard to the International Standard Organization's JTC-1 committee for fast-track consideration of its adoption as an international standard. As of July, 2007, that process is ongoing.

If the ISO adopts OOXML as a standard, this will have significant implications, as many national, regional and municipal governments mandate the use of a standard format in public schools and for all official government documents and records. In an increasingly electronic and on-line document world, the accessibility of this format has clear implications for members of disadvantaged or minority communities and persons with disabilities, as access to educational materials, government services, records, opportunities, participation and representation is at stake. Hence, accessibility should be a crucial prerequisite for standardization and adoption. With this in mind, this paper undertakes a preliminary analysis of the OOXML format with respect to its accessibility, with emphasis on accessibility to persons with disabilities. We will demonstrate that the OOXML format fails to adequately support accessibility of documents.

1.1. Description of Some Relevant Accessibility Challenges

There are a wide variety of disabilities that can hinder reading, understanding, creating, publishing, editing and exchanging documents. It is beyond the scope of this paper to describe the nuances and special accessibility needs associated with of each of these, an undertaking that is complicated by the fact that each person and situation is unique and it is always hard to generalize across individuals based on just a few attributes. Instead, we will present a couple of “paradigmatic” examples of obvious relevance to accessing and processing information in electronic documents. The two broad categories of disability that we will consider here are visual and motor. Our purpose is to provide some context for later technical examples of where OOXML fails with respect to these rather than to completely characterize them.

There are many forms of vision impairment that can limit document access, ranging from complete blindness to low vision to color and motion blindness. Further, document access can be visually restricted when people are operating in low-light or eyes-free environments, or using mobile devices with small screen sizes. Such situations and use constraints commonly lead to (1) the need to rescale and/or reformat documents such that the same content can be presented in a variety of different sizes and presentation styles, and/or (2) the use of assistive technologies such as screen readers or refreshable Braille displays that attempt to present visual content auditorily or tactily. Each of these present access-to-information challenges. In the first case, unless a document is designed to support resizing (for example, with the use of scalable fonts and graphics formats, with organizational structure made clear via appropriate meta-tagging, and with stylistic information clearly delineated such that it can be manipulated independently of content, etc.), major distortions from a document's intended meaning and effect can occur. (Consider that spatial relationships and layout are often used to represent other forms of semantic relationship, such as parallel lists. These must be preserved.) The second case is even more difficult as it requires software that can interface with common office applications for reading and editing documents. This software must be able to intelligently interpret document structure to distinguish different kinds of text, such as headers and web links, and must be able to facilitate alternative ways of editing given the added temporal constraints that a non-visual interface imposes. Further, many elements in documents require special mark-up in order to make them accessible at all. For example, without alternative text tags, images and drawings are completely inaccessible. Finally, as in the case of scaling, this mode of interaction presents difficulties with respect to loss of structure, as well as leading to loss of global context (where one is in the document), due to the serialization forced by the more sequential nature of non-visual presentation.

Motor impairments can also limit document access, sometimes in similar ways to those just described. Of course, as with visual impairments there is also a huge range of variation here, from total lack of movement to the inability to entirely or precisely control movement (such as in Cerebral Palsy) to pain or fatigue that accompanies movement, and there are also situations where motor accessibility is constrained for any user (such as when driving a car). Motor impairments can have implications for both the hardware devices and software used to access documents. For example, people with carpal tunnel syndrome need alternatives to a standard keyboard and mouse as input devices, as do persons with quadriplegia. Alternatives here depend on the type and severity of the impairment and include ergonomic keyboards, on-screen keyboards, and voice interfaces. Document editing applications should include alternatives as well, including short-cut icons and keystrokes for common operations, the flattening of menu hierarchies, optimization of menu content, and predictive text completion to reduce the amount of physical work a user must do in order to input and modify text. Most of these approaches deal with accessibility in the user interface of the office application rather than at the level of underlying document format. However, there are cases where the underlying document format must also support assistive technology, including cases where document elements must be resized to allow a user with imprecise motor control to be able to click on them with a mouse or cases where a form's layout must be modified, for example to support a person who must print out the form on paper in a special way in order to fill it out by hand. The issues here are similar to those described above with respect to scaling documents.

Special emphasis should be made here with respect to forms, as documents containing these are very important to make accessible (given their widespread use within governments, schools, and other important bureaucratic organizations). In both the cases of visual and motor disabilities it is important to support the reorganization of form layouts, which requires the ability to keep an entry field together with the label that describes what information should be entered by the user within that field. For example, if the label “Address” is associated with a 3-line blank, these three lines should maintain their proximity to the word “Address” in any reorganization of the form. For assistive technology to support this while simultaneously allowing flexibility in how the Address field relates to other fields on the form requires that the assistive technology somehow be able to associate the label text with the field it labels so it can keep them together while moving other things around. This association will usually not be explicitly represented to the user, but should always be present in the underlying XML representation of the document.

1.2. Manifestations of Inaccessibility

The previous paragraph presented necessary, but not sufficient, conditions for a document format to be considered accessible. Although it is impossible to spell out a complete set of sufficient conditions that would be generally applicable in all contexts, we can be guided by a core requirement articulated at a February 2007 workshop on open document exchange formats:

For all parties involved, the exchange of documents and data between authorities, businesses and citizens must be possible without technical barriers. The public administration must not exclude anyone from participating in an electronic procedure owing to the use of a specific product.³

Note that the primary target here is the ability to exchange information, inherent in the right to participate in society. This is of course connected with the lower-level standardization goals of document portability and interoperability, but puts the emphasis on the desired outcome for the people involved.

To this end, we would like to suggest an expanded set of principles necessary for the acceptance of a suitable open document exchange format (ODEF), derived from the above requirement and from directives in the European Council eAccessibility Resolution of February 2003 and the 2006 Riga declaration on “ICT for an Inclusive Society”.⁴                         

1. Standards processes, from initial conception and development to disputes related to standard conformance, must include a peer-review body of disability experts, developers of assistive technologies and people with disabilities.                     

2. All people, whether they have a disability or not and regardless of disability, should have the same choices with respect to the office software suite to be used for producing, accessing and exchanging documents and the hardware and software platforms on which these applications run.

3. An open document exchange format must be conducive to converting into other formats used by people with disabilities for similar and related tasks (including things like Braille books and formats like the DAISY talking book standard).

4. The benefits of introducing a new document standard (or modifying an existing standard) must be commensurate with the costs. It must be recognized that “costs” of new standards—in terms of money and time—are higher for people with disabilities because of the the costs of acquiring and learning the new or upgraded assistive technologies. (Note that for formats that do not support accessibility, the “cost of access” is basically infinite.)

5. The “marginal costs of access” to documents should be affordable and commensurate for people with and without disabilities. 

Unfortunately, it appears that OOXML fails to uphold all of these principles, as will be discussed below.

1.3. Overview

In what follows, we present evidence of shortcomings with respect to the above principles from multiple levels of analysis, starting from a high level with concerns about the process by which OOXML came about, followed by issues with the standard in general, and finally focusing on specific technical issues that will place an undue, and in some cases insurmountable, burden on developers of AT applications, rendering the format inaccessible. It should be noted at the outset that this paper is not meant to serve as a substitute for a thorough accessibility review undertaken by a diverse team of disability experts, with inclusion and active participation of persons with disabilities. Rather, with this cursory glance we hope to demonstrate the urgent need for such a review.

2. Issues with Development Process

As described in Section 1 above, OOXML was originally developed by Microsoft Corporation for their proprietary Microsoft Office suite as an alternative to previous proprietary document formats. Microsoft has not released details about how the standard was developed with respect to accessibility issues, but there is much evidence to support the inference that there was little or no consultation with disabilities communities or developers of assistive technologies, including:          

• that here was no public call for participation or commentary with respect to accessibility issues;
• that there is no reference to such a process in the available documentation within and about the standard;
• the standard itself frequently mentions its goals, such as compatibility with documents created in “legacy” applications, and the following statement from the Foreword:

• The goal is to enable the implementation of the Office Open XML formats by the widest set of tools and platforms, fostering interoperability across office productivity applications and line-of-business systems, as well as to support and strengthen document archival and preservation, all in a way that is fully compatible with the large existing investments in Microsoft Office documents. (Part 1, page xii)

but it fails to mention universal accessibility, disabilities or AT anywhere;                         

• the continued existence of the many problems detailed herein (found with only a cursory review) that render OOXML virtually inaccessible for its intended uses in all practical respects;                         
• the publication by Microsoft of a white paper on July 7, 2007 (well after it had been presented to ISO JTC-1) that was presented as a “preliminary draft report describing how Office Open XML compares to W3C Web Content Accessibility Guidelines and W3C XML Accessibility guidelines.”⁵ Note that the primary author of this paper, Gray Knowlton (Group Product Manager for Microsoft Office) stated in response to a recent blog posting about it that “[i]t was not intended to be a definitive guide to accessibility of Open XML”⁶, nor could it be as its evaluation was only based on an internal comparison of the specification to the W3C Web Content Accessibility Guidelines (WCAG 1.0, http://www.w3.org/TR/WAI-WEBCONTENT) and the W3C XML Accessibility Guidelines (http://www.w3.org/TR/xag), but not on a thorough review by all of the respective stakeholders. No such guide has been produced, nor does it appear that one is forthcoming.
• that neither of the two leading academic centre's in the field of accessibility, the Trace Center at the University of Wisconsin-Madison and the Adaptive Technology Resource Centre (ATRC) at the University of Toronto, were consulted at any point, despite the fact that these organizations are very active in assisting international standards efforts with respect to accessibility and have the R&D facilities, entrenched contacts with disabilities communities, and expertise to conduct thorough reviews if given enough time.

Thus, the development of the standard fails to meet one of the core principles for accessibility presented in Section 1.3 above. Accessibility concerns seem an afterthought at best.

3. General Issues

In Section 1.2 above, some necessary conditions for accessibility of a document standard were presented. These included that a standard:

• is easy to follow [3.1]
• is consistent, without a large number of exceptions [3.1];
• uses other open standards wherever possible [3.2];  
• harmonizes with other standards in the domain [3.3]; and
• makes necessary semantics programmatically available to the assistive technology [3.4]. 

This section will explain how the OOXML standard fails on each of these points.

3.1. Length, Opacity and Inconsistency of the OOXML Standard

Many individuals and organizations have complained about the length and opacity of the standard in the context of the ISO JTC-1 fast-track process.⁷⁸⁹ The standard is over 6,000 pages long , a fact made ironic by its sparse descriptions of many behaviours (e.g., see Section 3.4 below) and made worse by its poor organization. One reason for the inordinate length is that the standard includes descriptions of many modules that are unique to it. Most of these modules are variations of functionality for which standards already exist. This poses accessibility problems that will be dealt with in the next subsection. But the length poses other accessibility problems as well because it makes it more susceptible to internal inconsistencies. Indeed, in the short time since it has been introduced, many of these have been found.¹⁰ These violate the principles of Section 1.2 by making it very hard to interface with applications that implement these document features. Despite the defense by Ecma that these features are optional¹¹, AT vendors do not have the luxury of “skipping a feature:” AT must be compatible with all possible features that may be used to create documents. If anyone uses or has ever used the specified feature, an individual with a disability may encounter the feature and the AT must be capable of appropriately processing it.

3.2. Does not make use of applicable open standards

An electronic document format must be able to represent many types of content in addition to text, such as links, form fields and controls, equations, graphics (for drawings, clip art, images, graphs, etc.), and other embedded multimedia for audio and video (especially in the context of presentation documents). For each of these content types, there are existing standards and “best practices”. Indeed, accessibility concerns figured prominently in the development of most of these standards. These include:

Content Type	Accessible Standard
Forms	W3C XForms
Graphics	W3C Scalable Vector Graphics (SVG)
Links	W3C XLinks
Equations	W3C MathML
Multimedia	W3C Synchronized Multimedia Integration Language (SMIL)

 Table 1. Accessible standards existing for various content types.

However, in all of these cases, OOXML bypassed these accessibility-vetted approaches in favor of immature and functionally redundant approaches (some obviously based on proprietary Microsoft formats that have never before been presented openly and for which details are scarce). This not only violates the principles set forth in Section 1.3, but also the spirit of Guideline 11 of the W3C web accessibility guidelines. As such, OOXML increases the burden on AT developers, who must now decipher and support alternative ways of doing similar things, even if it were the case that each of these content representations were amenable to AT, for which they have yet to be vetted.

This seems to have followed a general trend within OOXML, as non-conformance with numerous international standards have been found in the proposal, including divergences from or contradictions with ISO 8601 (representation of dates and times) , ISO 639 (codes for the representation of names and languages), ISO 216 (paper sizes), ISO/IEC 8632 (Computer Graphics Metafile) , ISO/IEC 10118-3, W3C XML-ENC, and other cryptographic hash standards.¹²¹³ While these probably have less specific implications to accessibility than those in the above table, they do still violate the principles from Section 1 by forcing AT vendors to maintain special cases over and above the standard ones.

Finally, OOXML bypasses the single most relevant standard in its domain, ISO/IEC 26300, the “Open Document Format for Office Applications” standard. This is important enough to warrant its own section.

3.3 OOXML competes with the existing Open Document Format (ODF) for Office Applications standard (ISO/IEC 26300)

Many others have addressed these points from various angles. For example, one argument here is that the OOXML standards development process did not follow the proper due process for standards which would have been to forward any missing user requirements and perceived shortcomings of the current open document standard (see 3.2) to the ISO JTC1 project editors and seek improvements or extensions there, as opposed to proposing an entirely new, competing standard. This would have led to the open consultation of groups concerned with accessibility (cf. Section 2 above).

There is also a bigger accessibility issue here. As ODF and OOXML largely fill the same space – at least in terms of applications and AT that must support them – the competition between the two will be detrimental to the disabilities communities by (1) increasing the burden on AT developers and vendors to support multiple formats and (2) increasing the number of AT “plug-ins” and “band-aids” that users with disabilities will need to keep up to date on their systems just to inter-operate with both standards. Assistive technologies add an additional level of complexity to any user interaction with an application. When creating an AT-mediated system the possible incompatibilities brought about by each upgrade or modification are at minimum doubled. The effect of two standards serving a similar purpose is far more costly for AT developers and AT users.

3.4 OOXML makes reference to proprietary (closed) behaviours and formats

The OOXML standard makes numerous references to proprietary behaviours and formats. For example, in ECMA-376¹⁴, Part 4, Section 2.15.3, there are at least 12 elements defined that make reference to application-specific behaviours from legacy applications without specifying what these behaviours are. These include:

• shapeLayoutLikeWW8                       
• autoSpaceLikeWord95
• wpSpaceWidth
• footnoteLayoutLikeWW8
• mwSmallCaps
• suppressTopSpacingWP
• truncateFontHeightsLikeWP6
• useWord2002TableStyleRules
• wpJustification
• uiCompat97To2003
• useWord97LineBreakRules
• lineWrapLikeWord6.

For example, in Part 4, Section 2.15.3.63, an element called “useWord2002TableStyleRules” is introduced. This is how it is described:

This element specifies that applications shall emulate the behavior of a previously existing word processing application (Microsoft Word 2002) when determining the formatting resulting from table styles applied to tables within a WordprocessingML document.

[Guidance: To faithfully replicate this behavior, applications must imitate the behavior of that application, which involves many possible behaviors and cannot be faithfully placed into narrative for this Office Open XML Standard. If applications wish to match this behavior, they must utilize and duplicate the output of those applications. It is recommended that applications not intentionally replicate this behavior as it was deprecated due to issues with its output, and is maintained only for compatibility with existing documents from that application.]

This is the extent of the definition of the element. There are many accessibility problems inherent in a “standard” like this. For example, note that the behavior being referred to is not specified anywhere else in the standard, nor in any other non-proprietary documentation. Further, from this short description there is not even enough detail for AT developers to decide if this element will have an impact on AT, such as screen readers (that, recall, must be aware of table structure). And, as discussed above, since AT developers must support this element, given that Ecma felt this feature was important or widespread enough to include in the standard, there are still existing documents for which this tag will be marked that must be made accessible. Note that many of these elements specify behaviours related to the spatial organization of a document, something that is extremely important for AT to understand, as discussed in Section 1.1 above.

Not only is there insufficient detail as to how to replicate these behaviours, but referring to this proprietary behaviour makes it difficult for developers to make compatible AT. They are forced to reverse engineer out-of-date software applications (most of which explicitly prohibit such in their licensing agreements). Furthermore, it is unclear if they can ever legally implement the behaviors. The reason for concern is Microsoft's “Open Specification Promise” which states¹⁵:

To clarify, “Microsoft Necessary Claims” are those claims of Microsoft-owned or Microsoft-controlled patents that are necessary to implement only the required portions of the Covered Specification that are described in detail and not merely referenced in such Specification. “Covered Specifications” are listed below.

Note that things that are merely “referenced” by the Specification (as, for example, the behaviours referenced in section 2.15.3 of Part 4, presumably) are not exempt from Microsoft IP claims. If this is really the case, then a majority of vendors will have limited legal options when faced with attributes like these, except to ignore them. In effect, this would mean that the only vendors capable of correctly and legally displaying legacy Microsoft documents in a backwards compatible way (without licensing) would be Microsoft. Specifying that they are “optional” simply means that only AT vendors that enter into a licensing agreement with the vendor of the legacy application (Microsoft or Corel) will be able to make the affected documents fully accessible. This obviously violates the core requirement from Section 1.3.

Finally, by making these proprietary behaviors part of the standard (as opposed to application-specific extensions specified in a separate XML element, as in Part 5 of ECMA-376, with more support denoting how applications should deal with tags they do not understand), increases the necessary complexity of AT for all applications – by, for example, requiring special case handling to be maintained in software – when the elements only apply to specific applications. These features hurt interoperability as documents that contain them will not be completely portable, thus undermining one of the points of having an open standard in the first place.

The problems are similar with respect to proprietary formats referenced in the standard. For example, the standard makes reference to the “Windows Metafiles” and “Enhanced Metafiles”, both of which are proprietary formats specific to the Windows operating system. (Note that ISO/IEC 8632 for “Computer Graphics Metafiles” could have been used instead.) For example, ECMA-376, Part 4, Section 6.4.3.1 specifies the “ST_CF (Clipboard Format Type)” type, a string whose purpose is to specify the allowed clipboard formats. The standard says:

The following are possible enumeration values for this type:

Enumeration Value	Description
Bitmap (Bitmap)	Bitmap.
Pict (EMF)	Enhanced metafile.
PictOld (WMF)	Windows metafile.
PictPrint (Printer Picture)	An image rendered using the default printer's settings. This is typically a higher resolution and scaled differently compared to a picture for on-screen rendering.
PictScreen (Screen Picture EMF)	An image rendered using screen settings. This is typically lower resolution than an image created for printing.

 Table 2: ECMA-376 ST_CF types

Note that although the standard language does not specify that these are the only values this type can take, it clearly specifies that these are possible values that it may take. Hence, because it is possible that a document might contain a Windows Metafile, assistive technology must be able to understand this format; yet this format remains proprietary.

It should be clear that all of this defies the principles set forth in Section 1.

4. Specific Technical Issues

In this section, we will present specific technical issues with the OOXML format itself, each of which would directly hinder accessibility and the development of assistive technology for the format. For this, we have relied primarily on two sources: ECMA-376, the standard under review within ISO¹⁶, and the Microsoft white-paper referred to in Section 2 above [and the Preface] evaluating the standard with respect to two of W3C's accessibility guidelines (WCAG1.0 and XAG). In what follows, the issue will be specified with reference to these two sources as either “ECMA-376” or “MS Accessibility Report”.

4.1. Labels cannot be associated with form fields

Source: ECMA-376, Part 4, Section 2.16.17, page 1585 and MS Accessibility Report, WCAG Checkpoint 10.2, page 24 and WCAG Checkpoint 12.4, page 30

There is no explicit relationship between a label and its associated form field (textInput - 2.16.33, checkBox - 2.16.7, and ddList – 2.16.7), nor is there a way to specify the proper positioning of a label with respect to the form field. Note that a field's Name is not the same as a Label. (These have been treated as distinct concepts in all electronic form applications, including Microsoft Access forms, for years.) This distinction becomes clear if one considers the case of associating a single label with multiple form fields (for example, in “Check all that apply...” scenarios). Given the importance of accessible forms, as described above in Section 1.1, this issue alone is probably enough to warrant rejection of OOXML.

4.1.1. Response to revision 1.01 of the MS Accessibility Report

Relevant text in revision 1.01 of the MS Accessibility Report:

“The Open XML format allows for form controls to be grouped with the surrounding text.  In grouping the form control with the surrounding text it makes it clear what the label for the form control is.”

First, an example is needed here.  (The grouping examples earlier in the document mainly apply in DrawingML to pictures.)

Grouping is not enough if it is left ambiguous (i.e. not explicit in the markup) as to which element in the group is the label. This is especially problematic when grouping multiple things (such as controls or fields) under a single label.  Furthermore, this still doesn't provide a way to specify the proper positioning of a label with respect to the form field. 

4.2. Unable to associate a caption or summary with a table.

Source: ECMA-376, Part 4, Section 2.4.55, page 440 and MS Accessibility Report, WCAG Checkpoint 5.5, page 20

For many persons with visual disabilities, tables are very difficult to process via a screen reader. Unfortunately, in OOXML there is no provision for table summaries whatsoever, and although captions can be provided in a document near a table, there is no way to specify in markup the table to which the caption refers. Hence, persons with visual disabilities have no reliable alternative means of getting at table content via AT. Given the widespread use of tables in important government and educational materials (for example, tax tables in the United States' Federal 1040 tax forms), this issue presents a major barrier and would contravene many legislative requirements.

4.2.1. Response to revision 1.01 of the MS Accessibility Report

Relevant text in revision 1.01 of the MS Accessibility Report:

“Part 4, Section 2.15.1.6 describes how captions can be applied to tables as well as other types of content within WordProcessingML.”

Part 4, Section 2.15.1.6 is titled "attachedTemplate (Attached Document Template)"!  Not only does this seem to have absolutely nothing to do with summaries or captions, there is nothing in that section that would indicate how templates might be used (if at all) to acheive the linkage between captions/summaries and tables.  The text in that section is as follows:

This element specifies the location of a document template which shall be attached to the current WordprocessingML document if it is accessible and of a format supported by an application. Specifically, this element's val attribute shall contain the file path of the associated document template.

If this element is omitted, then the document shall not have an attached document template, and applications should use their default template in its place.

Note that the "attachedTemplate" XML element is specified as admitting only one attribute, "id", which specifies "the relationship ID to a specified part".  (Further, note that there is an error in this section with respect to this attribute's name.  Early on it is
named "val" but later, in the table and XML Schema, it is named "id".)

There is no distinction offered between summaries and captions, and there still appears to be no way to specify in markup the table to which a caption refers.  (And no example is offered in the MS Accessibility Report.)

4.3. Unable to associate (multi-level) table cells with their headers

Source: MS Accessibility Report, WCAG Checkpoint 5.2, page 18

In tables that contain multiple levels of row and column headers, there is no way to associate a table cell with the specific column and row headers that apply to it. As such tables are very complex to navigate in a serialized manner (e.g., auditorily through a screen reader) given, for example, natural limits on human short-term memory, allowing a person with a visual impairment to be able to keep track of where they are in such a table is essential. This is also necessary to assist users with short-term memory impairments. Other visual impairments, while not requiring the use of a screen reader, make it difficult to visually track across a row or column in a multi-level table from a cell to its header label and back, to look this up. It must always be possible to retrieve the column and row labels that denote a designated position in a table.

4.3.1. Response to revision 1.01 of the MS Accessibility Report

Relevant text in revision 1.01 of the MS Accessibility Report:

“Open XML Formats allow for multiple contiguous rows to be marked as heading rows, in which case they take on the behavior of a heading row such as repeating across multiple pages.”  [an XML example is given]

There is a difference between multiple levels of headers and “multiple contiguous rows” in a (single) header row!  The reason is that there needs to be a way to associate the subheading with the particular heading cells under which they fall.  For example, the following needs to be distinguished:

Main Heading 1		Main Heading 2
Subheading 1		Subheading 2a	Subheading 2b

from:

Main Heading 1		Main Heading 2
Subheading 1a	Subheading 1b	Subheading 2

(Note that adding empty, "dummy columns", as their XML example would seem to require for the above case, is not an adequate solution for a variety of reasons.)

Crucially, the XML example only shows how to make tables with multiple header rows but NOT how to associate a particular table cell (from somewhere else in the table) with the specific column and row headers that apply to it.  Thus, the main point of the checkpoint remains unsupported.

Finally, note the MS response (including the example) only covers heading rows and does not mention heading columns.  It is not clear if this is supported at all, even to the minimal extent that multiple header rows is.

4.4. No logical tab or navigation order through links, presentation elements, form controls and objects

Source: MS Accessibility Report, WCAG Checkpoint 9.4, page 24

Tab or navigation ordering is essential in forms which must be reorganized (as described in Section 1.1) to allow the form elements to be presented to the user in an order that makes sense. In many cases, without proper ordering of form fields, there is no way to determine the intended meaning of a field, even when given its associated label. For example, consider the following two potential arrangements for an electronic form:

SAMPLE FORM 1

HOME ADDRESS	WORK ADDRESS
Street: _______________________	Street: _______________________
City: ________________________	City: ________________________
State/Province: ________________	State/Province: ________________
Zip/Postal Code: _______________	Zip/Postal Code: _______________

SAMPLE FORM 2

HOME ADDRESS Street: _________City: _________State/Prov.: ___Zip Code: _____ WORK ADDRESS Street: _________City: _________State/Prov.: ___Zip Code: _____

As is, a screen reader would not know that it should not read horizontally across the form lines on Sample Form 1, and neither of these forms support reorganization by an AT (e.g., to make the text or field lines larger) because the label names (like “Zip/Postal Code”) do not uniquely identify the field groupings to which the fields belong. Hence, forms like these will be inaccessible for the reasons described in Section 1.1 above.

There is also no way to explicitly specify the navigation order among elements on a presentation slide (see ECMA-376, Part 4, Section 4.4). Thus, all presentations are inaccessible to screen readers, which will not know in what order to process the elements. (Note: this is not just a problem with reorganization or resizing.)

4.4.1. Response to revision 1.01 of the MS Accessibility Report

Relevant text in revision 1.01 of the MS Accessibility Report:

“This is not supported within Open XML explicitly, but can be easily achieved. Structured document tags can be used within Open XML to identify and label content using any defined vocabulary, including logical reading order.”

This is not enough.  This needs to be a full-fledged part of the standard for portability/interoperability across applications and so AT can know what to look for consistently.  

4.5. Alternate text descriptions for image maps not supported

Source: MS Accessibility Report, WCAG Checkpoint 1.2, page 8

Specifying alternate text descriptions for individual regions of image maps is not fully supported. So any interactive document that requires clicking on an image region (for example, one displaying a map and asking the user to click on their state or province) cannot be made accessible.

4.5.1. Response to revision 1.01 of the MS Accessibility Report

Relevant text in revision 1.01 of the MS Accessibility Report:

“By grouping images (which do support alternative text for images), a document equivalent of an image map can be included in an Open XML document. Grouped objects also support alternate text decriptions in the Open XML format specification.

“This information for the individual images is stored in the <wp:docPr/> element's descr attribute and the URL is located in a different file that the "content.xml" called "document.xml.rels" under "word\_rels" folder in Open XML file format.”  [an XML example is also included]

The example here is somewhat helpful, although it does not show how to achieve the grouping and it remains unclear whether this sort of aggregation of images provides an adequate replacement for a native image map.  In lieu of an example, Microsoft refers us to "Part 4, Section 2.1.6.7" which does not exist!  (This problem occurs in other places in the MS Accessibilty Report as well. In this particular instance, we suspect they mean Section 5.1.2.1.6 and/or 5.1.2.1.7, but this still doesn't substitute for an example.) 

Further, Microsoft's proposal requires creating an image map using a grouping of images which is very awkward and is not the method most content authors use to create image maps. It is therefore not likely to be applied, meaning most "normal" image maps will be inaccessible.

4.6. Non-standard colour names and values

Source: ECMA-376, Part 4, Section 2.18.46, page 1738-40 and 5.1.12.48, page 453117

In Section 2.18.46, OOXML does not use the same meaning for their colour names as is used in the W3C Scalable Vector Graphics (SVG) standard. For example, “darkgreen” is defined by OOXML as #008000 but by SVG as #006400, “darkgray” is defined by OOXML as #808080 but by SVG as #A9A9A9, “lightgray” is defined by OOXML as #C0C0C0 but by SVG as #D3D3D3, etc.. (Note that the differences between light and dark versions of the same color are not even the same between OOXML and SVG.) In contrast, Section 5.1.12.48 introduces new names for existing SVG mappings. In this section, “dkGray” is used to refer to #A9A9A9.

These definitions are more than just a matter of taste; they mean that AT solutions developed for SVG modules to deal with vision impairments (for example, that utilize dark and light colours for high contrast to assist people with low vision, or that manipulate the colour space to assist people with color blindness) will not be directly portable to, or inter-operable with application software designed to work natively with OOXML. (And in cases where AT is manipulating the colour space, these mappings may not be trivial.)

4.7. Disabling user interface features for particular browsers

Source: ECMA-376, Part 4, Section 2.15.2.32, page 1337-8

OOXML includes an element called “optimizeForBrowser” that “specifies whether applications should attempt to detect the target web browser for any web page produced from this document, and subsequently disable all user interface and output which is not supported by that target web browser.” Although there are a few examples for how an application might determine a document's “target web browser” for a limited set of browsers, there is insufficient detail as how to do this in general, nor is it specified how to determine the particular features supported by the browser once the target has been determined. Furthermore, storing this tag in the document file (as opposed to allowing it to be specified subsequently only be saved as HTML suitable for display in a single browser.

The accessibility concern here is that this tag allows individual document authors, in effect, to restrict which browsers, and hence which ATs (if any!), can be used to access web pages generated from their OOXML document in the future. (Other tags in Section 2.15.2 have similar problems, including “doNotRelyOnCSS” (2.15.2.11), “allowPNG” (2.15.2.1), and “relyOnVML” (2.15.2.34).) This means that even if there are advances in assistive technology for particular disabilities after the publication of a document, the document will not be extensible and will remain “stagnantly” inaccessible to these disabilities despite the advances. Further, given that many authors are unaware of accessibility issues, not to mention compatibility requirements of AT, inclusion of this tag makes creating an inadvertently inaccessible document likely. (Given the naming of this element with the word “optimize” it is probable that authors of office applications will be more likely to misunderstand its intent and use it by default.)

4.8. No context and orientation for frames

Source: MS Accessibility Report, WCAG Checkpoints 12.1 and 12.2, page s 29-30

In many documents, non-textual content is put into special regions enclosed by their own “frames”. As the format of the content in these regions tends to be “special”, it tends to be less accessible . Thus, it is important to be able to provide alternative text descriptions for frames as well as information as to how the frame fits into the document context and relates to other frames (including the main text frame) in terms of navigation order and other semantic relationships. OOXML does not support any of this.

4.8.1. Response to revision 1.01 of the MS Accessibility Report

Relevant text in revision 1.01 of the MS Accessibility Report:

“In an Open XML document with multiple frames, each frame can be given a unique title, which helps in the identification and navigation of the frame collection. This is supported in the Open XML formats, as described in section 2.15.2.16.”

“Frames have a defined name, and frame contents are referenced to source content using a relationship ID, which references the frame contents. This provides suitable context for identifying frame contents and their relationships.”

First, section 2.15.2.16 is under the parent section "2.15.2 Web Page Settings", even though this checkpoint should apply to frames of any sort, not just frames within web pages.  So it remains unclear whether Checkpoint 12.1 can be completely supported in all document contexts.  

Second, the description here of how one might specify relationships among frames is inadequate.  A single consistent way to do this needs to be specified as part of the standard, not left to the inventiveness of each application (for portability/interoperability across applications and so AT can know what to look for consistently). 

4.9. No way to associate multiple alternatives with images and tables

Source: MS Accessibility Report, XAG Checkpoint 1.2, page 35

As described in many places above, it must be possible to provide textual alternatives to visual content such as images and tables. It is obviously important to be able to explicitly associate an XML element containing an alternate text description with the object (image or table) it describes (something that is not possible in OOXML for tables, see Section 4.2 above). This section, however, deals with the case where multiple alternatives are associated with an object like an image or table. In OOXML, there is no way to explicitly associate or express relationships among these alternatives such that, for example, AT can determine that they all refer to the same object but that one of the alternatives is to be preferred over another in certain contexts.

4.9.1. Response to revision 1.01 of the MS Accessibility Report

Relevant text in revision 1.01 of the MS Accessibility Report:

“The Open XML formats provide significant capability for building relationships between types of content within the specification. The use of custom defined schemas within Open XML enables user-defined definitions of information within documents, which could include references to alternative content. The presence of custom schemas within the Open XML formats offers enormous flexibility in associating multiple variants of content to a single type.”

The problem here is not simply providing users flexible ways of associating multiple types of alternative content with a type, but (1) standardizing how this is done (so that AT can sort out the alternatives in a way that is consistent and portable across applications) and (2) providing a standard way to explicitly associate or express relationships among these alternatives ("such that, for example, AT can determine that they all refer to the same object but that one of the alternatives is to be preferred over another in certain contexts").

5. Conclusions

There are grave issues with respect to the accessibility of Office Open XML as a format and potential standard that should preclude its adoption at present. It may be the case that OOXML can be improved to ameliorate some of the more specific technical concerns, but it is most likely too late for the higher-level issues, especially those inherent in the process by which OOXML was developed. We suggest that energy would be better spent in the ongoing effort to improve the existing ISO ODF standard (with which OOXML would overlap and compete if it is adopted). In any event, decisions with respect to standardized document formats should be made in consultation with members of disability communities, disabilities experts and developers of assistive technologies, with universal accessibility as a core requirement as opposed to an ad hoc afterthought.

 

6. Addendum [added in Version 1.3] 

After briefly investigating Microsoft's revision (1.01) to their report, “Accessibility of Ecma Office Open XML File Formats”, we are more disappointed than ever.  The superficial change in their claims about what is and is not supported seems to be (1) a deliberate attempt to circumvent the spirit of the accessibility guidelines and checkpoints to 'whitewash' OOXML and/or (2) a demonstration of incompetence and lack of understanding with respect to accessibility.  Further, we would like to re-emphasize the need for consistent, clear, and interoperable means of providing information to Assistive Technology, requirements that are sorely lacking in the accessibility "solutions" offered by Microsoft and in the proposed OOXML standard itself.  We conclude by reiterating, with renewed urgency, that there can be no substitute for a thorough accessibility review by experts, including developers of assistive technologies and members of disability communities, for standards that are as fundamental and important as this. 

 

References:

1 ATRC. Correspondence may be addressed to Jutta Treviranus, Director of the ATRC, at This e-mail address is being protected from spam bots, you need JavaScript enabled to view it .

2 “Standard ECMA-376: Office Open XML File Formats”. Retrieved from http://www.ecma-international.org/publications/standards/Ecma-376.htm on July 19, 2007.

3 Workshop on Open Document Exchange Formats (ODEF). Held 28 February 2007 in Berlin. Organized by the German Presidency of the European Council in collaboration with the IDABC Programme of the European Commission. Program can be found at http://ec.europa.eu/idabc/servlets/Doc?id=27811.

4 These are deliberately similar to the four principles proposed by accessibility expert Peter Korn in his weblog entry of March 8, 2007. Retrieved from http://blogs.sun.com/korn/date/20070308 on July 19, 2007.

7 “Response Document: National Body Comments from 30-day Review Period of the Fast Track Ballot for ISO/IEC DIS 29500 (ECMA-376) 'Open Office File Formats'”, prepared by Ecma International February 28, 2007, retrieved from http://www.ecma-international.org/news/TC45_current_work/Ecma%20responses.pdf on July 19, 2007.

8 http://www.incits.org/DIS29500/DIS29500.html accessed July 19, 2007.

9.http://forums.scc.ca/forums/scc/dispatch.cgi/public/docProfile/100009/d2007051143554/No/t100009.htm accessed July 19, 2007.

10 Many of these inconsistencies are highlighted at http://www.grokdoc.net/index.php/EOOXML_objections accessed on July 19, 2007.

11 “Response Document: National Body Comments from 30-day Review Period of the Fast Track Ballot for ISO/IEC DIS 29500 (ECMA-376) 'Open Office File Formats'”. Prepared by Ecma International February 28, 2007, retrieved from http://www.ecma-international.org/news/TC45_current_work/Ecma%20responses.pdf on July 19, 2007.

12 “EOOXML Objections”. Retrieved from http://www.grocdoc.net/index.php/EOOXML_objections on July 19, 2007.

13 “Response Document: National Body Comments from 30-day Review Period of the Fast Track Ballot for ISO/IEC DIS 29500 (ECMA-376) 'Open Office File Formats'”. Prepared by Ecma International February 28, 2007, retrieved from http://www.ecma-international.org/news/TC45_current_work/Ecma%20responses.pdf on July 19, 2007.

14 “Standard ECMA-376: Office Open XML File Formats”. Retrieved from http://www.ecma-international.org/publications/standards/Ecma-376.htm on July 19, 2007.

16 “Standard ECMA-376: Office Open XML File Formats”. Retrieved from http://www.ecma-international.org/publications/standards/Ecma-376.htm on July 19, 2007.

17 Originally reported in “EOOXML Objections”. Retrieved from http://www.grocdoc.net/index.php/EOOXML_objections on July 19, 2007.