Tuesday July 03, 2007

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:

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 openxmldeveloper.org 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" (2007-07-03 17:07:48.0) Permalink Comments [1]

Sun's OpenDocument Format plugin for MS Office now shipping

As my colleague Malte Timmermann has pointed out earlier today, the Sun ODF Plug-in 1.0 for Microsoft Office is now available for download, free of charge.

The plug-in is an extension to Microsoft Office that allows it to read and write ISO standard ODF files. It supports Office 2000, XP, and 2003, and works on Windows XP and Vista. It adds to MS Office the ability to read and write ODF text, spreadsheet, and presentation files (.odt, .ods, and .odp) - the ISO standard editions of MS Word, Excel, and PowerPoint files. Furthermore, ODF text files (.odt) can be made the default format for MS-Word thanks to this plug-in (and double-clicking on an ODF text file on the desktop would automatically open it in MS-Word).

Addressing the accessibility concerns of existing MS-Office users was one of the key reasons behind Sun's development of the ODF plug-in, and I have been one of several folks involved in testing the accessibility of this plug-in (along with several beta testers whose employees with disabilities were likewise doing accessibility testing). I'm delighted to report that all aspects of the plug-in - from installation through to operation from within MS-Office - works very well with commercial Windows AT products. The ODF plug-in works very well with screen reader and screen magnifiers and voice recognition/dictation systems and text-creation assistance applications. It likewise works well with the basic accessibility features built into Windows - with themes for folks with visual impairments and with the limited MS-Windows built-in AT like Narrator* and Magnifier. This means that existing users of MS-Office can move to ODF without sacrificing any of the accessibility they have achieved, because they need never leave MS-Office.

* Note: Narrator doesn't read MS-Office content, because Microsoft doesn't support its own screen reader with its own office applications, unlike UNIX distributions like Solaris and Ubuntu, which ship with a screen reader that is able to read (and Braille) office application documents. Unfortunately the ODF plug-in is unable to change this, so Narrator won't read ODF files anymore than it can read Word, Excel, or PowerPoint files. (2007-07-03 13:33:53.0) Permalink Comments [5]