Late last week, Gray Knowlton wrote a lengthy blog comment, sharing some of this thoughts about my review of the Microsoft white paper "Accessibility of Ecma Office Open XML File Formats" that Gray posted to the OpenXML Developer website. Given the importance of the office document accessibility, and the attention that ODF and MSOXML are getting with respect to accessibility, I wanted to continue the conversation directly in my blog (vs. buried in a comment to his comment). The rest of this is written directly to Gray...
First, Gray, thank you for talking the time to have this discussion - and thank you for correcting my misspelling of your name (oops!). You mentioned that you undertook this review "in part to educate a few individuals who claimed that “Open XML does not support accessibility”" but that "it was not intended to be a definitive guide to accessibility of Open XML". Can you tell me, has Microsoft - or anyone else - done a thorough review of MSOXML accessibility? Education, and "correction" of "significant misunderstandings" is one thing; a thoughtful and thorough accessibility review is another. Is this white paper the former, or the latter? If as you say it is the former, what about that thoughtful and thorough accessibility review?
Gray, at the start of your blog comment you say "I’m not sure that the “who did this?” question matters as much as your post seems to indicate", and you spend several paragraphs describing your (non-accessibility) background at Microsoft and Adobe. You also noted the name Reed Shaffner, as "a member of my team specifically focused on the accessibility of the Microsoft Office system", though you don't mention whether he was involved in writing this white paper (by the way, is this Reed Shaffner the author of these two blog posts? the new hire from Duke University who last year was a college senior and who presented a paper Linking Pgm allozyme and nucleotide variation in
blue mussels at a Colorado Evolution conference?).
The reason I raise the question of authorship of the white paper is to better ascertain the level of accessibility expertise involved in the review. MSOXML has gone through the ECMA standards process, and is up for vote and adoption by the International Standards Organization, and is being evaluated by many countries and U.S. States for use and standardization in their organizations. Knowing whether a thoughtful and thorough accessibility evaluation was done on MSOXML has an impact on folks in many of these places.
Elsewhere in your comments, regarding my question about the use of WCAG 1.0, you note: "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." I understand that issue, but then why do you use the XML Accessibility guidelines, which are only in draft form? It doesn't seem consistent to me...
And speaking of questions, I hope that we can continue this conversation, and that you might address the other questions I raised in my review. To quickly summarize them:
Blog question #2 (unaddressed):When and how will the accessibility failings cited in the paper be fixed?
In your evaluation, you note that MSOXML fails to support WCAG 1.0 checkpoints 4.2, 5.2, 9.4, 10.2, 12.1, 12.2, and 12.4, and that MSOXML only partially supports checkpoints WCAG 1.0 checkpoints 6.4, 8.1, 9.1, and 11.1. Some of these have quite significant impacts on folks with disabilities, including especially those who use assistive technologies to access office documents. For example, WCAG 1.0 Checkpoint 9.4 requires that you have a logical TAB order through all of the links, form controls, and objects within a document. Without this, keyboard only users won't be able to get to and manipulate all document content; screen reader users may miss some sections of content altogether. Another example: WCAG 1.0 Checkpoint 12.4 requires that all labels be explicitly associated with the objects they are labeling. Without this, blind folks using screen readers have a lot of trouble figuring out what a control is when they TAB so it - imaging hearing "edit field; edit field; edit field" as you TAB through a form, instead of "name edit field; address edit field; city edit field".
Blog question #4 (unaddressed): How does MSOXML meet accessibility needs outside of WCAG 1.0 & the W3C XML Accessibility draft? How well does MSOXML support translating into DAISY and Braille?
Perhaps your comment "The scope of the original project was not intended to provide the more significant contribution to the accessibility community you describe in your post" answers this, but it wasn't clear to me from your reply, and I don't want to make poor assumptions (misspelling your name is bad enough!). Does Microsoft know how well MSOXML supports the requirements of DAISY book creation? How well is supports the creation of Braille publications? How well it meets other accessibility needs? Does Microsoft have any experienced accessibility people looking at MSOXML, evaluating against accessibility needs independent of W3C accessibility specs?
Blog question #5 (unaddressed): Is there a difference between the phrases "supported" and "fully supported" in the white paper? When the white paper says that a provision is only "partially supported", what is missing?
Since you use "supported" in some places, and "fully supported" in others, it strongly implies there is a difference. Is there? Is merely "supported" less than full support? And when you note that MSOXML only "partially supports" an accessibility checkpoint, you don't say what is missing. Could you please elaborate on that missing support?
Blog question #6 (unaddressed): Why is the white paper so lacking in clear "supports" statements about the XML Accessibility guidelines?
The style change from the white paper text about WCAG 1.0 vs. XML Accessibility checkpoints almost suggests two different authors. But whatever the reason for it, it leaves a reader like me unable to form a clear picture of how MSOXML stacks up against the XML Accessibility checkpoints.
Separate from these questions - which I hope to read your answers to soon - I want to touch again on this comment of yours: "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 OpenXMLDeveloper.org specifically for this reason. I do hope this project can become the contribution that you and others have expressed interest in evaluating." Many people - me among them - are not in a position to review a 6,000+ page specification. Microsoft has been working on accessibility for at least the past 20 years, and is the author of that that massive specification. Shouldn't Microsoft have its experienced accessibility experts working on this, rather than hoping that others work on it for you?
On a different topic, I'm curious about your comment regarding my P.S. about an accessibility problem I noted in the PDF edition of the white paper. You said: "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." Did you use Word 2007 to create the white paper, and the Export to PDF function to create the PDF? In other words, is this the result of a bug in the accessibility functionality of Word 2007's PDF export feature (as you say that you need Adobe Acrobat to "edit the PDF to correct this easily")?
Finally, fair is fair. You asked me a question:
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.
First, let me forward you to Andrew Kirkpatrick of Adobe, who writes the Adobe Accessibility Blog, and who along with me and 40 other folks is a member of the Telecommunications and Electronic and Information Technology Advisory Committee providing recommendations for updates of accessibility standards issued under section 508 of the Rehabilitation Act and guidelines under Section 255 of the Telecommunications Act. Perhaps you met Andrew during your time at Adobe? In any case, Andrew and Adobe are the experts on PDF accessibility, not me and Sun...
That said, please let me observe that PDF/X-1a (also known as ISO 15930-1:2001) and PDF/X-3 (also known as ISO 15930-3:2002) are "graphic technology standards" for use in "prepress digital data exchange". They are subsets of the full PDF standard. They are not for editable office documents; rather they are for the final step in a print document's life prior to being sent to the printer (whether that document started out life as a spreadsheet or a glossy 4-color magazine advertisement). Mathematical equation editing happens upstream - in places like office documents or other formats dedicated to preserving all of the semantic meaning of the equation. Likewise the gathering of form data.
Anyway, where I believe it makes sense to ask these questions is with PDF/A-1 (also known as
ISO 19005-1:2005). This is a "document management" standard, which is described as an "electronic document file format for long-term preservation". It is here (rather than while in transit to a printer) that the preservation of accessibility information is important, and where our accessibility attentions make sense. I haven't yet read that standard, so I can't speak to what W3C specifications it does or does not incorporate. As I find out more, I'll post the answers here.