Reviewing the "Accessibility of Ecma Office Open XML File Formats"

Since the start of the discussions around office document accessibility nearly two years ago - with the publication of Commonwealth of Massachusetts' Enterprise Technical Reference Model v3.5 in September 2005 specifying the use of OpenDocument format for office documents - I have seen NO clear and technical discussion of the accessibility of the Microsoft OXML format. Rather, in meetings I've been part of, Microsoft representatives have simply stated that since Microsoft Office is accessible (only when running on Microsoft Windows, and for the blind only when running with expensive 3rd party assistive technologies), it is automatically the case that the underlying file format fully supports everything needed for accessibility. This has been the first, last, and only word on the accessibility of MSOXML even while many European countries and American States have considered standardizing on an office file format - and grappled with accessibility concerns arising from that consideration. And while several folks I know in the accessibility field have contemplated undertaking such an evaluation of the file format, the 6,000+ page specification for MSOXML proved an effective deterrent.

That finally changed yesterday morning, with the publication of the "Accessibility of Ecma Office Open XML File Formats" white paper at the OpenXML Developer website. This welcome - if late - development allows us to finally start to have a real technical discussion of MSOXML accessibility, and to start to compare MSOXML accessibility support to what is in OpenDocument Format v1.1.

The 38 page "white paper discusses the Accessibility features of Open XML and using the Web Content Accessibility Guidelines 1.0 and XML Accessibility Guidelines ." It begins with this cover text:

Microsoft is offering this document as a contribution to, to further understanding of Open XML within the development community. Microsoft offers this to as a project to which others may contribute, to help improve the support for assistive technology in the development of software using the Ecma Office Open XML Format Specification.

This Microsoft-proffered document goes through each of the checkpoints of the May 1999 Web Content Accessibility Guidelines v1.0, and the 3rd Draft, October 2002 XML Accessibility Guidelines, and describes whether and how MSOXML supports these checkpoints. One particularly nice thing this document does for many of the checkpoints is to illustrate in XML precisely which MSOXML tags one would use to support that checkpoint. For example, for Checkpoint 1.1 of WCAG 1.0, on pages 7 & 8 the white paper shows how to use the tag to annotate shapes, grouped objects, and line/arrows with text equivalents, and the tag to do the same thing for images, charts, and 3D objects. These XML fragment illustrations are present for most of the provisions that Microsoft claims MSOXML supports.

While a very welcome contribution to the discussion of office file format accessibility, this document raises a number of new questions, even as it answers others:

  1. Who did this review? The white paper contains no list of authors, nor even the name of one or more groups at Microsoft. The only person associated with this document is Gray Knowlton, an member with no bio, and only one posting to the website to date. He appears to be a Group Product Manager for Microsoft Office, focused on Technical Product Management. What about people with accessibility expertise at Microsoft? I presume at least one of them was involved, but with what background? What about folks from the disability community. Was anyone with technical background from a blindness organization invited to contribute? Anyone with physical impairment expertise? Anyone making assistive technologies? Anyone making file conversion software to take office documents into Braille or DAISY? It is difficult to trust a document that has no attribution. Given the high stakes involved, it is difficult to accept something without peer review from experts that don't stand to profit from the results of the review.

  2. When and how will the accessibility failings cited in the paper be fixed? While the white paper introduction notes that the "adoption of Accessibility in the Open XML standard will help many technology providers carry forward the information stored in billions of existing documents AND preserve the information in that document intended to enable accessibility", it is silent on the question of whether how MSOXML accessibility support itself will improve. For example, the white paper notes that MSOXML fails to support WCAG 1.0 checkpoints 4.2, 5.2, 9.4, 10.2, 12.1, 12.2, and 12.4. The white paper further notes that MSOXML only partially supports checkpoints WCAG 1.0 checkpoints 6.4, 8.1, 9.1, and 11.1. Some of these are particularly important for blind users needing to understand the context of table cells and for good Braille and DAISY transcription of tables - issues we found in ODF v1.0 and fixed in ODF v1.1. Will these things get fixed in the future? If so, when? By whom? With what outside review (if any)? To appear in what update of the specification?

  3. Why use WCAG 1.0? It is widely recognized that WCAG 1.0 is very old. The Web Content Accessibility Guidelines v2.0 is in ""last call". The white paper uses a draft of the XML accessibility specification, but then oddly doesn't do the same with WCAG 2.0, relying instead on a document that is over 8 years old.

  4. The white paper notes in many places that many of the WCAG 1.0 checkpoints are inappropriate for an office document (this is separate from the checkpoints noted above that the document says are either not supported or not fully supported). This suggests that the document author(s) don't feel that WCAG 1.0 is a fully appropriate standard to use. Yet there is no discussion about this - about why those standards were chosen and not others. Also no discussion about the accessibility purposes to which one might put an office document (e.g. meeting the needs of Braille or DAISY transcription).

  5. The white paper sometimes uses the phrase "this checkpoint is fully supported in Open XML file format", and other times the phrase "this checkpoint is supported in Open XML file format" (as distinct from the phrasing "this checkpoint is partially supported in Open XML file format". Is there a difference between "supported" and "fully supported"? For those checkpoints that are merely "supported", what is missing (if anything)? Further, in many cases for checkpoints that are "partially supported", often the white paper doesn't state what is missing. Without undertaking a thorough reading of the 6,000+ specification, it is difficult to know exactly what is missing. Without knowing who did this review and wrote this white paper, there is nobody we can ask this question of...

  6. In the review of MSOXML against the XML Accessibility guidelines, there is no definitive statement on whether and how MSOXML supports the first 8 checkpoints (1.1 through 3.2); only summaries of what those checkpoints say. For many other XML Accessibility guidelines checkpoints, there is some description of what MSOXML does, but no definitive statement about whether that means that the checkpoint is "fully supported", "supported", or "partially supported" by MSOXML (or yet some other thing). Does this mean that MSOXML fails to support those checkpoints? Does it mean that the checkpoints are inappropriate for an office document? Something else? It just isn't clear.

In addition to these important questions, this white paper nicely sidesteps what I believe is the intent of WGAG 1.0's Guideline 11: "Using W3C technologies and guidelines", and most specifically checkpoint 11.1 "Use W3C technologies when they are available and appropriate for a task and use the latest versions when supported." Unlike ODF, MSOXML makes almost no use of existing W3C standards. Instead of using the W3C XForms specification for embedded forms, it invents its own XML terminology for forms. Instead of using the SVG specification for vector graphics, it uses its own vector graphics encoding. Instead of using the MathML specification for mathematical equations, it uses its own math encoding. Instead of using the W3C date format, it invents its own (and perpetuates a leap year bug from the first releases of Microsoft Excel, rather than having the software that converts from .xls into MSOXML calculate the correct value). Yet oddly, on this topic, the white paper claims that checkpoint 11.1 is "partially supported", with the checky claim that "the Open XML file format has defined namespaces and elements and use [sic] them." This lack of re-use of existing (and accessibility-vetted) W3C XML standards is perhaps the main reason for the MSOXML specification running to 6,000+ pages, and is repeatedly cited by ISO voting members in their objections to the Fast Track ballot of MSOXML.

P.S. a final note: I was disappointed to see that the PDF edition of this white paper failed to make full use of the accessibility features of PDF and be a properly tagged document. The first 8 words of the document appear doubled to screen readers: "AAcccceessssiibbiilliittyy ooff EEccmmaa OOffffiiccee OOppeenn XXMMLL FFiillee FFoorrmmaattss"


Hi Peter,

Thank you very much for you post. I am the person driving this project. “Gary”, however, is my evil twin; I’ve heard a lot about him, but never met him in person. My name is actually “Gray.” (This will help you learn more about my history with PDF, InfoPath and Open XML.) I’m not sure that the “who did this?” question matters as much as your post seems to indicate, but this should help you learn more.

You are correct that my role at Microsoft is leading a technical product management team for Office client applications. Open XML is among the topics we address, I also believe you’ve had an opportunity to meet with Reed Shaffner, a member of my team specifically focused on the accessibility of the Microsoft Office system. I spend a majority of my time working on Open XML adoption, and helping Microsoft Office administrators users understand the impact of a file format change. Part of what I do involves fact-finding research, to inform our public communication and to educate people internally about the use of Office and related technologies.

(In case you were interested) prior to Microsoft, I worked for Adobe, on the Adobe Acrobat product management team. My primary contribution to the product was to improve the creative professional functionality supported in Acrobat 6 & 7. Most relevant to this discussion; PDF/X-1a and PDF/X-3 support were added to the product as part of the desire to promote the use of PDF within the professional printing industry. I was involved in the addition of PDF/A support as well.

The sum of my personal time investment in document format standards-related work is approximately 6 years. I am not the person who signs up to sit in the committee; I am the person trying to turn these standards into actionable products which have value to people. I have spent time working with organizations like DDAP ( and BFMA ( to better understand how standards that may benefit a particular community are actually used (or not used, in many cases).

I’ll state right up front that I have a strong distaste for the hair-pulling and shin-kicking that goes on in the Open XML discussion. Because my primary interest in Open XML (and any other document format) is related to the people who use the software, the energy I spend on Open XML is devoted to helping IT professionals plan for a transition into a more open environment, helping partners and developers take advantage of these new formats, and ensuring that the benefit of more open file formats are realized with minimal disruption for people who use our software.

The research I posted on was developed in part to educate a few individuals who claimed that “Open XML does not support accessibility.” – To give the commenter the benefit of the doubt, it was to correct some significant misunderstanding they were perpetuating about the specification. It was not intended to be a definitive guide to accessibility of Open XML. We are aware that the WCAG1.0 guidelines might not be the most appropriate of benchmarks today, but there are few finalised alternatives. I do work with our accessibility team on evaluating Open XML against the developing standards, and as I am sure you are aware we are active participants in these processes; however it would not be appropriate at this point to publish anything until those efforts are completed.

The scope of the original project was not intended to provide the more significant contribution to the accessibility community you describe in your post, but I posted this project to specifically for this reason. I do hope this project can become the contribution that you and others have expressed interest in evaluating.

Much like the ODF Translator project on SourceForge, I felt that this project provide might provide greater benefit to the accessibility community if it was conducted in public. I hope that our accessibility partners and the Open XML community at large can utilize this information to improve accessibility support within their products. I do plan to submit this research to Ecma for consideration in future versions of the Open XML standard; Ecma 376 has great accessibility support in its current form (and really didn’t need to be prodded in public to do so), it would seem that Ecma TC-45 is amenable to the topic.

So, consider your feedback on how the evaluation might be improved as noted and under consideration for the next phase of the project (which is to do more research and highlight more examples.) And, THANK YOU. I absolutely welcome your participation in this effort, and I am very happy to hear additional thoughts you have on accessibility of Open XML.

I’ll also offer you an apology for the condition of the PDF posted on the project. Having been a product manager of Acrobat in the past, I am somewhat embarrassed to have not used the tools in Acrobat for making PDF documents more accessible. I did create a Tagged PDF, as you noted, but I haven’t installed Acrobat on my new hardware yet, so I did not have the ability to edit the PDF to correct this easily. (Just to dispel any conspiracy theories.)

Speaking of PDF, would you mind please pointing out the list of W3C recommendations supported by PDF/X-1a, PDF/X-3 and PDF/A? It’s been a few years, but I don’t recall the use of XForms, SVG or MathML in these specifications. These are all ISO standards today, so I’m curious to compare this with the ODF example you cited in your post.

Gray Knowlton,
Group Product Manager
Microsoft Office

Posted by Gray Knowlton on July 06, 2007 at 01:11 AM PDT #

Post a Comment:
Comments are closed for this entry.

Peter Korn


« September 2016